Am 26.05.2013 03:08, schrieb Tim E. Real: > 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. wait, you haven't understood my point. Exactly this is what I want! (This is actually on my to do list.)
> 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...) nooo! I at least want an option which actually does this behaviour! Not necessarily named "mute", and not neccessarily the default. > > 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. same here, i would say. Example where you want muting only notes, but not controllers: Your song relies on the interference of multiple tracks (because you wanted to separate various melody patterns into separate tracks, which drive the same output. Now you think there's a dissonance, and mute one of these melody patterns. You would now expect that your song behaves as previously, just without these notes. Controller messages must be still passed then. > > And problems with the other method 2) and its little sub-solution: honestly, method 2) sucks. It's a dirty, dirty hack that better should be done right. If you want the meters to move, then you must change the *semantic* meaning of the meters: From "displays the port state" to "displays, what this track would actually output". Greetings, flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
