Request ability to mute staff (as opposed to instrument, or voice)

Mac OSX 10.14. I don't hear the difference in MuseScore 2 and MuseScore Alpha 2 playback of the attached score. Could you export score audio locally to mp3 and attach the result here?

As far as I can tell, this score contains one instrument with two staves, not linked, and the notes are all set to play. I can't think of a reason why you shouldn't hear two sounds for each note, with all the audio artifacts the laws of physics demand in such cases. Could be some subtle different in soundfont prevented this artifact from being noticed as much previously, but I can't see any reason one should expect this score to playback without the artifacts that are known to occur in these cases.

As far as I can tell, this score contains one instrument with two staves, not linked, and the notes are all set to play. I can't think of a reason why you shouldn't hear two sounds for each note, with all the audio artifacts the laws of physics demand in such cases. Could be some subtle different in soundfont prevented this artifact from being noticed as much previously, but I can't see any reason one should expect this score to playback without the artifacts that are known to occur in these cases.

Is there something I'm missing? If not. let's close this.

I wasn't aware of any feature in 2.x. Was this ever documented? If so, can you point to the relevant documentation so I can understand how it was intended to work? Since the normal expected result of having two staves both containing notes would be that they both actually play and export, this as likely to me to have been a bug, perhaps a manifestation of the same issue that caused overlapping notes of the same pitch on the same channel to get cut off prematurely.

If it was a documented feature in 2.x that somehow tab staves were special-cased and exempted from the normal way playback works, then we should indeed consider adding that feature back. But as I said. I am not aware of any such feature,

I think there are still open questions as to what exactly is going on, but based on what I've been able to determine, I think it clear enough there is no bug in either 2.3.2 or 3.0, it's just differences in behavior that are both perfectly valid. And I understand you have a preference for the older behavior and why, but there are also valid reasons behind the current behavior. To me, it's a valid feature request to want an easier and/or automatic way to suppress playback of identical notes on the second staff. So I am calling this what it is - a suggestion - and rewording accordingly. Please leave it this way. If any of the developers of the relevant code wish to weigh in and make further changes here, that's fine.

For more background:

I am almost positive there was no special feature in 2.3.2 to automatically detect you had a tab and standard staff on a guitar part and automatically switch off playback for the tab staff. After all, it clearly doesn't happen if the content is different - put different notes in the top and bottom staff in your example you'll hear them all play. It's only the cases where the notes on both staves happen to be the same where you only hear one. Are we agreed on that?

This much is neither a bug nor a feature in itself, it's just how it happens to work internally. My understanding is that the reason you are hearing only one note is to fix a bug that used to exist in older 2.x versions. In the original 2.0 and for some time afterwards, if you entered a half note C in the top staff, an eighth note C at the same time in the bottom, on playback the note would be cut short after the eighth - the longer C would be cut off. This has to do with how MIDI works. A whole bunch of possible solutions were devised, and different 2.x release actually used different solutions. But nowhere was it ever guaranteed the bottom line effect would be that only one note would sound - that was just one of the different ways put forth to solve the original problem of notes being cut short.

For 3.0, we are using a different solution to the original problem, one which allows both notes to actually sound, as requested by many. In particular, it's better for organ this way, and come to think of it, it's also better for guitar in some cases. Consider a whole note open E on high string of guitar at beginning of measure. Now on beat three, play an E on the fifth fret of the B string. You want to hear both notes at that point, don't you? My understanding is that the current method makes this possible; the old method cut off the first note when the second sounded.

Really, if you want notes on the second staff not to sound you shouldn't be relying on MuseScore to do this for you. Instead, you should mute them yourself, just as you would mute any other notes you have written into your score but don't want to hear. Currently, we don't have a way to do so by muting the staff as a whole (only the instrument). But that's a valid feature request. Currently, you need to select all notes and uncheck Play.

It's also a valid request to want there to be a way for this to somehow happen more automatically - like basically treat the previous behavior as if it were a feature. But the current behavior is actually better for other use cases, so probably there would have to still be some sort of option to specify which behavior you wanted, and perhaps then made part of a template.

For the record, the issue leading to all this is #12971: Same note in different voices and lengths plays only the length of the shortest note

Again, it's only a "bug" if you for some reason expect to be able to write two notes but only hear one of them despite taking no action to tell MsueScore this. To me, that's just not a reasonable thing to expect. Everywhere else in the entire program, you write two notes, you get two notes - in playback, in audio export, and in MIDI export, unless you take explicit action by muting one one of them. I get why you might want to have only one note here, but again every else in the entire program, if you have notes you have written and you want to not hear them, you need to take explicit action and mute them. I don't get why you would expect any different here.

If you want a note to have a staccato dot, you add the staccato dot. If you want it to be invisible, you mark it invisible. If you want it to be colored green, you color it green. And if you want it to not sound, you mute it. It really is as simple as that.

I tried a small file in which one voice crosses another in a "Pipe Organ" in MS3. It does the same thing as it did in 2.3.x, i.e., it interrupts and continues the long note when the short note hits it. This was the "re-strike" compromise @mirabilos and I and others agreed upon to fix the long-standing problem whereby short notes cut off long ones at the unison. This (re-strike) behavior is sometimes wanted and sometimes not; often you want "just don't play the short note at all" (if i is completely covered by the long note); perhaps the organ reference you make is that involving couplers, when mechanical or electrical action has implemented the latter policy for hundreds of years. In other cases, the organ is identical to any other keyboard model, including MIDI itself, wherein you only get one "key" for one note and crossing parts and unisons cannot be accurately played (yes, this includes playing the entire Well-Tempered Clavier on the pianoforte). The string instrument and choral cases are not performable on a single MIDI channel (or keyboard reduction); crossing/coincident parts on different strings or choral sections on the same staff require two discrete, simultaneous sounds.

MS "pipe organ" approximations also have a problem that the manuals and pedals are assigned the same MIDI channel/"virtual keyboard", falsely calling forth these issues when manual and pedal parts cross (but the General MIDI organ simulation is sufficiently horrible to smokescreen this, but some people have successfully used organ-registration sound-fonts (as opposed to Virtual Pipe Organ technology) where this is a real issue (but can easily be worked-around by supplying individual staves yourself)). Perhaps this (unwanted manual-pedal interference) is what you are alluding to.

I don't fully understand what you're saying because it is at times seems elusive about what it's describing or proposing. The current behavior (2.3.x and as far as I can tell 3.0 -- is it in fact different?) is tolerable. Per-score control over policy (re-strike vs no-restrike; in no case "cut-off") (I can't see how this can be a per-note control), as well as OPTIONAL midi-channel per staff-voice (the notion of "two orchestral parts on one staff" is indeed mentioned in the 3.0 documentation; Flute I and II on same staff indeed requires precisely this) is the only complete solution to the nest of related problems.

Am I addressing what you said with sufficient precision?

Since I am not as fully versed as others on the topic of the original issue of overlapping notes, I really don't know that there is more I can add here. I think we understand the situation about as well as possible. Bottom line is that, independently of whatever solution we end up with for the original overlap issues, we should include some sort of method to force the tab staff in scores like this (not linked, but content otherwise) to not play. Whether that's best done at the MIDI event level or via simply providing a means of muting the staff (and hopefully including this information in a template) is yet to be determined.

!!!!!!!!!!!! (those are real exclamation points)

I think you nailed it - good job keeping on this! The issue is not about subtle differences in the behavior of overlapping MIDI events, it is that your top staff has swing applied and the bottom doesn't, so all the offbeats are heard twice. Increase the ratio in Staff Text Properties to 75% and it becomes that much more obvious.

As for why, this is simple: the swing text was originally system text, but is being mis-read as staff text on import. That's because we changed how we define system text it's now its own element type, not just staff text with the system flag set as it was in 2x. We try to correct this on import but it only works for MSCX, not MSCZ. See #276235: System text from 2.3.2 imported as staff text (preventing to hide otherwise empty staff)

That also explains why removing the top staff removes the text - it's now staff text, not system text.

So, the playback artifact you were hearing is a duplicate of the known issue involving import of system text. I still think is makes sense to want a way to more easily mute the tab staff. So rather than close this as a duplicate of the known system text import issue, I've reverting it back to a simple suggestion for a "mute staff" feature.