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. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
