>> The only solution I can see is to allocate a channel when a track is
>> armed
>> for
>> recording. Have the act of toggling the LED trigger this, so it's in
>> place
>> and ready to go when the user hits record.
>
> The thing is, having had time to reflect on my last comments, it isn't
> recording that's semi-broken but playthru. Recording was just part of the
> use case that showed the problem. You can (always could) still record on
> any track. This is about how MIDI plays thru.
>
> ISTM it needs to play thru correctly even when not recording. I think now
> that Ted had it right: have a dedicated channel for the selected track. I
> had hoped to avoid coding that, because it seems potentially complex and I
> feared introducing any more bugs, but you have persuaded me that something
> like this is needed.
Having looked over the affected code more carefully, it seems like it will
have to be both. That is, even when recording, routeEvents can use either
selected track or armed track, depending on getInstrumentForEvent.
On the plus side, this looks doable and maybe not as complex as I feared.
Tom Breton (Tehom)
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
