On 9/8/2011 3:01 AM, William Zwicky wrote: > What if the delay depends on the nature of the change? Maybe parameter > changes are no problem, but those huge patch sets take a few seconds > to digest. It might be possible to send a request that is only > answered when the synth is done, or you might have to just set a 3 > second timer and hope. The sender could then store the latest value > received from the widget
Now it's getting trickier. My initial thought is that something like this should be handled in the synthdriver, because it's not an issue in *transferring* the data over the MIDI wires. See what I'm saying? There's the limit that the synth has in how many bytes per second it can gobble from the wires (which would be managed by the MIDI layer) and then there's any extra time that the synth needs to digest the data once it has been received. That second category might be best managed in the synthdriver. > Yeah, that's pretty much it. When a parameter changes but we cannot send, > we save the new value, and set a flag. When an opportunity to send arrives, > we scan for those flags and send the first one we find. But even this may > be synth-dependent -- if multiple params change, I may want to build a > single message that updates them all at once. Well, in the idea that I posed in my previous post, the MIDI layer would just accept changes until it decided that the queue was full and, when it was full, it would just throw exceptions to the widgets. The widgets would have the option to tell the MIDI layer to purge all other queued messages from the widget, etc. However, if it's the case that some synths support sysex message which update multiple parameters at once, then I can see the rationale for letting the widgets inspect all of their queued messages and then trading them out of a consolidated one. I can't think of a slick way of preserving their place in the queue, though. They'd either go right to the front of the queue or to the end. - Joe ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
