MEL coupler doesn't play note sometimes

[d-musique]

Hi. I'm finding the MEL to be a very useful feature, but unfortunately defective many times.
Problems occur when playing a pack of many notes, such as below, played in tight legato fashion.

It's because the selection of the MEL note is apparently sensitive to the order in which these note events arrive.

I could identify this section of code to be at fault:
Make the condition less strict by commenting out && nextNote == m_LastTone, and it works without issue.

grandorgue/src/grandorgue/model/GOCoupler.cpp

Lines 306 to 308 in b227bd1

	if (((velocity > 0 && nextNote == note)
	|| (velocity == 0 && nextNote == m_LastTone)))
	m_CurrentTone = nextNote;

The organ used is Kalvtrask Extended, but I don't think it's of any relevance.
GrandOrgue 3.13.0. Linux amd64

[larspalo]

No, it won't work, as already discussed in #1425.

As soon as you for instance want to repeat a bass or mel note the coupler starts jumping around to next note possible to target (which completely ruins voice leading), this also happen if you try some other articulation than legato in the bass or mel than a ridiculously tight legato. Musically, it's even worse to always have the next note in turn coupled than to miss a few notes (that mostly can be avoided by changing your way of playing). The only case where such a solution as you propose would work is if both the bass and mel always play with a continous legato with no gaps unless also all other voices are (already) lifted - which is a severe limitation for any more advanced playing.

[d-musique]

I see, it's an interesting discussion. I wouldn't mind to do some research and implementation myself, to improve this feature, which I value a lot.

Maybe this suggestion to improve the algorithm will be naive, in which case, please forgive; but I have in mind the following:

The algorithm might restrict the election of the next note, only to those who have their key-on event arrived chronologically after the activation of the last MEL tone.
This means, these low notes will not be accepted as jumping candidates, and it will not suffer the "back-and-forth" effect.

[larspalo]

@d-musique Sure, please test different implementations and post your findings! The big obstacle to get around is how to differ between an intended over-legato into the next note on one hand and avoid jumps when the line is just repeating the note or is indeed having a pause on the other...

[kerkovits]

I have been using a custom build of GO patched by the algorithm proposed by @larspalo at #1425 (comment) I am quite satisfied with it, as it is the best for my playing style.

[oleg68]

@larspalo might you add your implementation as a PR with an additional setting, which implementation to use?

[larspalo]

@oleg68 Where should that setting be available for selection? For each individual MEL and BAS coupler? For each manual that owns them? A global switch?

[oleg68]

@larspalo I think one global switch in the config dialog would be sufficient