Re: [Lmuse-user] Some (annoying) usability bug fixes in trunk now.

[Tim E. R. <ter...@ro...>]

Here's a fix for those who use multiple midi tracks on the same 
 output port and channel, such as (especially) multiple 'takes':

When you have multiple 'takes' of midi tracks on the same output
 port and channel, you will typically audition only one track at a time 
 and mute, or turn off, all other tracks.

There was a problem while seeking the play cursor, that any overlapping
 controller graphs on the same controller number in these muted/off 
 tracks were  still being processed even if the tracks were muted or off, 
 or the parts within them were muted.
This caused confusion of controllers because the app just arbitrarily
 sent the first value it can find from any graph regardless of mute or off.

This was most noticeable with say SUSTAIN CC(#64) graphs, such as from 
 several performance takes, in that while seeking the play cursor,
 in say the pianoroll, SUSTAIN was getting messed up, getting set to on 
 or off when it shouldn't be, due to contributions from the other graphs.

So now, the code which was supposed to ignore these muted or off 
 values has been fixed.

Just be aware as always, that multiple tracks on the same output port 
 and channel *can* cause confusion with overlapping controller graphs. 
Just that now, you can turn off or mute the offending tracks or parts, 
 and it should hopefully ignore them properly.

Hope I got the fix right, you can see it in MidiDevice::handleSeek().

@ Geoff:
I CC'd you because I think you were still reporting problems with SUSTAIN. 
Being a recording performer, likely working with multiple takes, this bug 
 would have annoyed for sure while moving the cursor around in the pianoroll.

Tim.

----------------------
- Fixed confused controllers on seek with multiple muted/off 
 midi tracks/parts on same port/channel. 
In MidiDevice::handleSeek(): Re-wrote controller value sending section - 
 fixed obeying mute/off section.