Re: [Lmuse-user] Midi users: Opinions needed: Meaning of midi track mute?

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

On May 23, 2013 09:26:02 PM Tim E. Real wrote:
> I've hit a bit of a snag I can't seem to decide.
> Some users may prefer to keep midi output traffic a low as possible.
> Other may prefer that features just work even if it may mean more traffic.
> 
> Should midi track 'Mute' inhibit sending of *all* midi messages to the
>  track's output port?
> Or should 'Mute' inhibit only *notes* but allow all other message types,
>  like controllers, to *always* pass through?
> 
> Here's the situmutation:
> 
> You will notice that in MusE, as the song progresses through midi controller
> graphs, midi GUI controls such as the controller graph knobs do *not*
> update when the track is *muted*.
> Also the knobs do not respond to midi from the chosen *input* routes
>  when the track is muted.
> 
> This is because these GUI controls represent the state of the *output*
> device.
> 
> Currently 'Mute' cuts off all input and playback messages to the output
> device.
> 
> The current design is such that we want these GUI controls to represent the
>  *exact* state of the output midi device AS BEST AS WE KNOW (we know
>  only what we last sent to it) and we must strive to make sure that the
>  knobs try to always represent the true state of the device.
> 
> Thus, if muted, we can't really update those controls because we haven't
>  sent any midi since muting, and the device is really in the last state
> before muting. So we don't want to break the 'accurate representation rule'
> - where the knob says one value and the device really has another.
> 
> There are cases where this 'no sending while muted rule' is broken:
> -----------------
> If the track is muted, the knobs are still enabled and users are allowed to
>  adjust them and, according to the 'accurate representation rule' above,
>  midi messages *are* sent - even while the track is muted.
> Otherwise, if we don't send midi messages, well that knob is not an accurate
> representation of the current device state - we would have to *disable*
> that knob just because we *muted* the track!
> 
> However, you'll notice if track is 'Off', midi strip controls *are*
> disabled. I forgot to disable Var/Rev/Cho knobs, maybe I should disable
> piano roll controller knobs too - and the whole TrackInfo! So these
> controls will also send midi while the track is muted, currently.
> 
> And there are cases where the 'accurate representation rule' is broken:
> ---------------
> MusE has a mechanism to update the midi GUI controls with new values
>  *without* sending any midi. We use it with caution when we know,
>  or think we know, the device state. An example is when you change a
>  control in a MusE Soft Synthesizer and it informs MusE to update its own
>  GUI controls - an example of full-duplex, whereas midi is *not*.
> We also use this mechanism when loading songs and a few other places,
>  or when we just don't know the true state and must put a value there.
> 
> The point about that last section is this:
> Users expect naturally that the knobs just work and will ask why the
>  knobs don't turn when muted when they have input routes connected
>  and are playing back and nothing is happening.
> 
> So there are two solutions - my indecision:
> 1)
> When a track is muted and midi controller input is received or played back,
>  *do* allow it through to the *output* device so that the knobs can be
>  updated and represent the true state of the output device as we know it.
> Drawback: Traffic! With many midi tracks driven from the same input,
>  or when simply playing, even with the track *muted* there's gonna be
> traffic on those outputs !
> Advantage: Output device, even hardware, always has truly current controller
> values even while track is muted.
> (Note: If and when midi automation modes are added, OFF mode would typically
> inhibit sending of midi graph data - there is currently no such inhibition,
> except when muted of course. But that still leaves the problem of live midi
> controller data from midi inputs.)
> 
> 2)
> When a track is muted and midi controller input is received or played back,
>  use the mechanism above to *update* the GUI controls but *not* send midi
>  to the output, thus keeping the output lines quiet.
> Drawback: Breaks the 'accurate representation rule' - the knob says one
> value but the output device really has another, being left in a state
> *before* mute was turned on.
> A solution to that last bit: Keep a record of the state just before mute,
>  and later when mute is turned off, compare that state record with the
> current state of the knobs (our internal midi controllers), and if there
> are differences from when we muted, do transmit them *now*.
> Drawback: Could be a lot of sudden traffic as soon as you un-mute.
> But not so bad - it's only one track and only a one-time burst of *altered*
>  controls after un-mute. Whereas solution 1) continuously sends data
>  when needed.
> 
> Lastly, there is our TrackInfo 'Midi Through' button !
> Here's a confounding case muddying all of the above. We simply *cannot*
>  send anything to the output device when midi thru is off and yet, we would
>  like the knobs to at least show us what might be arriving at inputs
>  (playback is sent normally, thru does not play a roll there).
> So here we're forced to use the solution of 2) to simply update the GUI
>  controls but absolutely never send midi to the output, if thru is off.
> Thus here the knobs are not an 'accurate representation' of the *output*
>  device state when thru is off. But, as with solution 2), we *could*
>  transmit our state as soon as midi thru is turned on again...
> 
> Hope y'all got that. Kinda, sorta see what I'm sayin'.
> 
> BTW Speaking of mute, off, and thru, I've added better protection for
>  'stuck' notes: Now when you mute, turn off thru or turn off the track,
>  *all* pending note-offs are played immediately, including 'live' input
>  notes for which we have not even received a note-off yet !
> The MusE 'stuck notes' handling was split into two sections: Our current
>  per-device stuck notes list (now only for trackless notes like metronome),
>  and a new per-track stuck notes list so that track mute/off/thru can
>  affect them.
> Oh, and as mentioned, it is no longer required to rec-arm a midi track
>  just to hear its input. Commits hopefully soon. See ya!
> 
> Thanks.
> Tim.


OK Thanks for the feedback.
Exactly the arguments I've been thinking of, and expected.

But seems I didn't think it through enough.

What was I thinking? I can't be sending controllers on muted midi tracks!
They will interfere with non-muted tracks on the same device/channel.
And users will go "what the heck, where's all this interference coming from?".
(I actually fixed these problems in the first place! Duh. Memory fades...)

Also, I suddenly realized another killer detail: Parts can be muted.
What then, eh? Am I gonna send their controller graphs so that GUI controls 
 can be updated? Nooo. It's pretty obvious for muted parts that mute means 
 'everything'. And that led me to rethink track mute again.

And problems with the other method 2) and its little sub-solution:
Sure, when track is un-muted I could send any pending controller changes,
 but what about other events like sysex messages which may have come in? 
I'd have to keep a record of them and send them when track is un-muted,
 which just feels kinda weird - bunching them up in a sudden burst like that,
 long after having been queued up in the first place.

Rats. Tough problem. Back to the drawing board...
Looks like I'm gonna have to do nothing for now, status quo folks.

Tim.