Re: [Jsynthlib-devel] Fwd: [Jsynthlib-cvs] SF.net SVN: jsynthlib:[1104] trunk/JSynthLib/core/Actions.java

[Joe E. <jo...@em...>]

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