musesampler_overlapping_notes

[RomanPudashkin]

Resolves: #15306

[Jojo-Schmitz]

Hmm, shouldn't that rather be a track for each voice (incidently called track internally)?

[cbjeukendrup]

@Jojo-Schmitz It looks like it is more complicated... This is what I understand of it by reading the code of this PR: (@RomanPudashkin please correct me if I'm wrong)

engraving's model: just a list of "tracks", where "staff index" and "voice" are completely determined by these tracks with the formula track = staffIdx * VOICES + voiceIdx

MuseSampler's model: apparently within one MuseSampler instance there is a concept of "tracks", and for events on these "tracks" you can additionally specify a "voice index". So, a MuseSampler instance has multiple tracks, and each track can contain multiple voices.

This results in the following mapping:

• engraving staff index -> MuseSampler track
• engraving voice -> MuseSampler voice

It's a bit overwhelming that the word "track" seems to have at least three different meanings now (one in engraving, one in the Mixer, and one in MuseSampler), but that seems to be just the way it is.

(Personally I had also expected that we would just abuse MuseSampler's voice API by specifying staffIndex * VOICES + voiceIndex, but apparently MuseSampler has an extra concept for different staves.)

[DmitryArefiev]

Tested #15306 on Win11, Mac13.6 - FIXED

[cbjeukendrup]

@RomanPudashkin I still have some doubts about that optimisation of doing this for keyboards only:

• Having multiple staves for non-keyboard instruments is very uncommon, so this optimisation won't have any effect for 99,95% of scores (uneducated estimation)
• In those cases where someone still uses multiple staves in a non-keyboard instrument, overlapping notes are actually even more probable than in keyboard music: in keyboard music, generally one staff is for the high range and the other for the low range, but in non-keyboard music both staves are likely to cover the same range. Consider for example the case where a violin section has to play divisi, divided into two subsections; naturally, both staves will play in a similar range (since for violin you wouldn't really use any other clef than G and the common range is not huge) so overlapping notes between these staves are actually more common and thus applying the fix to non-keyboard staves is actually even more worthwhile than for keyboard staves.

[basaigh]

As a harpist, the two staves are quite often used to denote what each hand plays, not always having anything to do with pitch ranges. The issue of the same note being played twice is also particularly prevalent on harp as once you pluck/strike the string the note will hold without interaction, leaving the string free for either hand to use it immediately.
I've been watching the attached issue for quite a while now, and would really appreciate if the fix was not limited to keyboard instruments.

[MarcSabatella]

I agree - while multiple staves not common for non-keyboard instruments (well, besides harp, and marimba), when it does occur, it’s that much more likely to contain overlaps. Divisi parts are an obvious use case. Another might be SATB closed-score choral music if there is ever one generic “voice” sound covering the full range, or if the user substitutes something else. If an instrument has multiple staves for any reason, this is still a potential issue.

But - thank you so much for tackling this!

[dcorson-ticino-com]

I would say that multiple staves ARE common for divided strings.
I play viola in the local orchestra and per happenstance there are divided strings with multiple staves in all the 3 pieces we are playing in our next concert: Mendelssohn, Boccherini and Rossini.

[RomanPudashkin]

@cbjeukendrup the reason it was disabled for non-keyboards is not because we thought it wouldn't be needed for them, but because it just worked very poorly with non-keyboards... Fortunately, @konradglas (many thanks) managed to optimize adding tracks on the musesampler side, so we no longer need to disable it for other families

[DmitryArefiev]

Retested on Win10, Mac13.6 with musesampler 0.6.0.104 (and MuseSounds).
#15306 looks good on keys, Harp and Strings with divisi parts.
Scores with a lot of additional staves now took more RAM and CPU (when using musesampler v6) but it's expected and not critical