For a note block, if the base block underneath is pushed by a piston, no matter whether the new base block is the same as the old one, the note block's instrument will unconditionally changes to "harp" for a short period, because the base block is replaced by "moving piston" during piston pushing.
This behavior prevents the observer from telling the player whether the instrument (the base block's type) has changed, because observer will unconditionally emit a pulse for the temporary wrong "harp" instrument.
Therefore, personally I think the note block should not respond to state update derived from "moving piston", so note block's instrument type will be consistent if its base block type is consistent.
Attachments
Comments
migrated
Arisa Bot
ampolive
Thank you for your report!
We're tracking this issue in MC-123217, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
migrated
I've searched through the linked main ticket https://bugs.mojang.com/browse/MC-123217, and did not find a behavior related to the one in this issue. Possibly it's because this issue is not about the behavior of the moving block, but the block that interacts with the moving block (the note block).
This issue could certainly be fixed by dealing with the moving block (by attaching the information of original block/type of block to the moving block), but by considering the note block only, this issue could also be easily fixed by not updating instrument state when the block below is a moving piston block.
ampolive
The underlying issue is still MC-123217, the moving blocks don't retain the instrument of the original block. "harp" is just the default instrument.
migrated
Yes, this issue could be categorized to the underlying issue MC-123217.
The comment I wrote were mentioning that unlike the "Light opacity" and "Solid top" which is a property of original block itself, "instrument" is not original block's inherent property, but determined by another block (note block) and is the state of that block.
I didn't find relevant referenced issues in MC-123217 that isn't about some inherent properties of moving blocks (may be sculk sensor works the similar way with note block?), so I wrote the comment above to clarify this before categorizing this issue into MC-123217.
migrated
Additional note: this behavior makes the redstone block sorter in https://www.youtube.com/watch?v=uowEgO2bjBM works only one way (can detect harp -> another instrument), but not the other way around (from another instrument -> harp), because both another instrument -> another instrument and another instrument -> harp will trigger observer pulse, rendering the signal undistinguishable.
Hope this behavior could be fixed in 1.19 release, so it could be greatly utilized in the design of mud based clay farm.