Regression: Unison notes in a shortest value are not played

I suspect this is related to the sound font. I use the FluidR3Mono.sf2 sound font from around 8 March and it plays correctly in 2.2. This was before s.chriscollins started working on the sound font.

This is not “unison”, this is using separate voices. Voices are one instrument, and one MIDI channel.

For unison, you need separate MIDI channels, normally by using separate staff lines. (It also was not unison before that commit. Before, it just did not play the longer value.)

With a workaround, you can change your score to split them into separate MIDI channels (attached).

There will be a FAQ about it. I’ll do a couple of screenshots and write accompanying prose when I get the time, shortly,

I agree with cadiz1, this is a serious regression. Hopefully it can be fixed, but if it truly is a design limitation of the previous change, I see no alternative to but to recommend reverting it, because in this case the cure seems worse than the disease.

My understanding is that the new fixupMIDI() function works by discarding any subsequent notes of the same pitch that occur while a note is still playing. This means lots of notes that previously sounded will no longer sound. For certain instruments, this might be acceptable - it really wasn't going to be physically possible to play the subsequent note anyhow. But for guitar, also for staves that use multiple voices to represent multiple instruments (or actual voices), this is going to be unacceptable. For example, the following extremely simple passage does not render correctly in either 2.1 or 2.2, but it is far worse in 2.2 than in 2.1:

In 2.1, the worst that happens is the whole note in the first voice gets cut off early. Mildy annoying at worst. Now, the quarter note in the second voice (on beat 3) doesn't sound at all. Disastrous in comparison to 2.1, IMHO.

Sorry this didn't occur to me when initially reviewing the code, but am glad we get to see this now before release so we can consider how to deal with it.

As I re-read the thread for the original issue #12971: Same note in different voices and lengths plays only the length of the shortest note and see the various factors being discussed, I am thinking the "real" solution is to use different MIDI channels for the different voices on a staff, but this is out of the question for 2.2.

I think it plain that in the cases where two notes are sounded simultaneously, we want the longer to win. But in cases where a second note is struck sometime after the first, we have been assuming the desired result is for the second note to not sound at all so the first can continue, and this is, in hindsight, looking like the wrong decision.

So, what if we simply compromised, and continued to discard the shorter note in the first case (where two notes occur at the same tick) but not in the latter cas? It's actually a simpler algorithm, probably faster to process too, and I think gives better results, at least in these cases.

Or maybe there is some other case I am not considering where discard that second note really is preferable? I am having difficulty imagining it, frankly, but there seemed widespread agreement before that this made sense, and that must have been based on something?

You solution for the time being, until each voice can have its own midi channel, sounds good to me. It will seem to have little effect on instruments that do not have a natural decay to their sound like a guitar and piano do. IMHO it will sound better for those instruments.

Sorry if I chime in without knowing the full details of the implementation, but what about creating a "restrike" key scenario (i.e. at the overlapping note send noteoff+noteon signal, but let the second note sound until the end of the one ending at the latest time) and using it as an alternative to the current one (which is basically a "no restrike", if I understood correctly), depending on a (global?) MuseScore preference set by the user (basically a true/false button in I/O Preferences or similar place)?
ES:
Given:
note1                 |-------------|
note2                        |---|        we could have:
with restrike:    |----|-------|
no restrike:       |-------------|
Given:
note1                 |-------------|
note2                        |-----------|    we could have:
with restrike:    |----|-----------|
no restrike:       |-----------------|

In this case, a user who wants an audio output similar to an organ would just use a "no restrike" option, while a user who wants an output similar to a guitar would use a "restrike" option.
I don't know how difficult would be to implement this and, more importantly, if there would be time enough before the release of 2.2.
Unfortunately, I know really nothing about the midi output interface and I wouldn't even know where to start on it...

I'm in favour of Marc's proposal. Since classical/fingerstyle guitarists commonly use shared noteheads with different durations, this looks like a good solution.

Restrike is possible and it works with our internal synthesizer, not sure how well it would work for midi export or even MIDI out though... It seems the best solution to me. Ok it sounds a bit weird for organ but hell... YouTube video and PR to come.

Together with my fix for #270408: Broken visual tracking of colliding notes, it looks and sounds like this: https://www.youtube.com/watch?v=U3q-myLLUbM

The current implementation (the one cadiz1 does not seeem to like) does precisely that: the longer note wins.

2.1 would just discard the LONGER note. So, the 2.2 snapshot being complained about plays MORE sound than 2.1 ever did. (In this particular score excerpt, it plays the same AMOUNT of notes as 2.1 did, just some are longer as in 2.1.)

Restrike in MIDI export for guitar with mp3 rendition from Garage Band (unzip it). Any feedback?

BSG might hate this because he needs the non-restriking behaviour, but I could personally live with that for 2.2.

So we’ll need to take notes for what would have to be changed post-2.2… I think the list has already grown to:
• easy way to split voices into separate MIDI channels
• (independent of that) a checkbox, per MIDI channel(!), whether it needs restriking behaviour or not (against the “natural” default, the majority of use cases seems to wish for restriking, so that could be the default)
• instruction of users to use split voices e.g. in SA/TB closed scores and not rely on restriking for those

For visual demo of playback, we’ll then use the current code for restriking channels and mine for non-restriking ones. That could be fun… (but possible) we’d have to merge them (looks doable).

Hm, wait a moment… if we use restriking, the playback fix from my PR would behave the same, as restriking is note off directly followed by note on… @lasconic, is that right? (That would make things easier. We could even use this in 2.2, even though it’s probably too late for an option to disable restriking there.)

Restriking needs to be enabled/disabled per MIDI channel, not per staff, voice, etc. because that’s where the logic happens.

Phew. Took me quite a while to think about it and compose this reply…

The notes are played. You just don’t hear them because they are already playing. This is already a great improvement over 2.1 in which they were actually not played.

if we use restriking, the playback fix from my PR would behave the same, as restriking is note off directly followed by note on…
I don't understand the question. Your PR refers to which PR exactly?

For later, let's speak later... but if we provide channel/voice assignment, restriking is off for me, no need for an option.

Proposed fix for 2.2 : https://github.com/musescore/MuseScore/pull/3560

If you are on windows (cadiz ;), you should be able to get a binary to test here https://ci.appveyor.com/project/MuseScore/musescore/build/1.0.843/artif… when the build is done.

With "my PR" I meant https://github.com/musescore/MuseScore/pull/3551 which, I think, will also work (for the visual display) when restriking is used.

I've just had another revelation: with restriking, there's a corner case we will have to watch out because it requires non-naive handling: multiple ME_NOTEON for same port/channel/note AT THE SAME TICK. I'll have a look at your PR for restriking, as I have a rough idea how to handle it starting from my code, but will have to see.

With "my PR" I meant https://github.com/musescore/MuseScore/pull/3551 which, I think, will also work (for the visual display) when restriking is used.

I don't think your PR would work for restriking. At least, not as it.

Hmm, it’s not all that trivial. Damn. (Yes, of course not as-is but with a slight tweak to provide restriking. I think I could make it work, but it’s harder than I thought at first.)

Considering your “if we provide channel/voice assignment, restriking is off for me, no need for an option” I won’t invest more time into thinking this over. I think your approach is good enough for the rapidly-approaching release, and that’s it then.

Short proof-of-concept that separate channel assignment also fixes playback, so we will indeed need “only” this past the release. (I already have a backwards-compatible idea for how to make this easy.)

Just to clarify something said earlier: "2.1 would just discard the LONGER note" - this is not true at all. The longer note was not discarded, it was simply cut short. We still got to hear both notes sound, it was only the length of one of the notes that was incorrect. This is infinitely better than an approach where one of the notes does not play at all. In the simple example I posted in https://musescore.org/en/node/270562#comment-825925, the melody line in voice 2 is just plain missing a note. Not playing the shorter note at all is far worse than cutting off the longer note early in this case. Which is why I suggested the partial solution of only discarding the shorter note when it occurs on the same tick as the longer note.

But indeed, if we are willing to consider using separate channels for voices for 2.2, then that's even better.

To me the restrike option as implemented and demonstrated above seems good, [EDIT: deleted comment about multiple note on's with only a single note off now that I understand better].

I am having trouble understanding the scenario in which not restriking is desired. Can someone show a simple example of when restriking would not be correct? Something about organ music I guess, but as a sometimes organist myself, I still am not seeing it.

2.2-dev revision: 1dd229330

Tested this with a range of guitar scores, classical and fingerstyle. e.g.

carcassi_etude_8.mscz

No playback problems to report.

OK. Thank you for the tests. We might have some issues with external MIDI hardware used with MIDI out in these cases but I hope the situation is better for everyone : guitar, organ and singers.

Fixed in branch 2.2, commit dc10b0e7a6

fix #270562: Regression: Unison notes in a shortest value are not played

Automatically closed -- issue fixed for 2 weeks with no activity.