Mordent/prall playback ignores key signature

• Mar 22, 2015 - 22:17
S4 - Minor

I'm surprised I never came across this before, but the nice new feature of playing back mordents—flickering briefly over the next note—ignores the key signature, and there seems to be no way to tell the ornament that (for example) "I want you to play the next note up as flat." Thus, the note is played out loudly in the wrong key. Clearly this will have to go to the 2.0 release as is, but perhaps someone could look into it for the 2.0.1 release?


Actually, it *does* take the key into account, or at least, tries too. Seems to get it right most of the time from what I can tell, but I think it is failing to take instrument transposition into account - or is doing so improperly. So, for example, a written B for alto saxophone in the key of A gets a lower neighbor of A# rather than A, because it is looking at the *concert* pitch D but calculating the lower neighbor for the written key of A - which yields C#. It then transposes that C# and gets A#.

If you are hearing cases that are *not* explained by this, please post the specific score so I can see what else might be going on.

EDIT: BTW, the workaround for this particular issue is, playback in Concert Pitch mode. Then it calculates the pitch based on the correct key signature.

Very interesting, and thank you for the workaround. It seems a little bit odd to me, but at least there's a way to make it work. Still, there should be a better way to handle this, so if it's all right I'd like to leave this open in the tracker.

Oh, of course - it's a bug to be sure, and I wasn't aware of it until you pointed out there might be a problem, because I actually tested this pretty extensively. I just guess I never tested with transposing instruments. So I just wanted to make sure that this is the only problem you are seieng - that it is working correctly *except* where transposing instruments are concerned. If so, it's literally a one-character fix: changing pitch() to epitch() at one spot in the code.

Right now? Well, 2.0 is frozen, so even if I made a change now, it wouldn't make 2.0. And until 2.0 is released, I'd just as soon not confuse the state of the code repository by introducing new commits that are not part of the release (even though in theory it should be possible). But no reason it could not be done soon after the release of 2.0 and thus be in nightly builds.