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

[frankster <jsy...@te...>]

On 09/08/11 11:01, William Zwicky wrote:
> On Thu, Sep 8, 2011 at 2:31 AM, frankster<jsy...@te...>wrote:
>
>> (just have each driver register a max amount per time frame it can handle).
>>
> 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.

Perhaps there are two classes of sysex/controller data to consider -
bulk dump and real-time patch change - and they can't be handled
the same.

>
> The sender could then store the latest value received from the widget
>> for a parameter, then check with
>> this central rate tracker whether its allowed to send or not, and if its
>> not allowed to send then it stores
>> the widget value and requests notification from the central rate tracker
>> when it would be ok to send.
>> In the meantime if any additional widget events come in before the
>> notification, they can store their values
>> too. Finally the notification comes through from the central rate
>> tracker and it sends it.
>>
>> Its getting a bit complicated because maybe if two widgets were modified
>> in close succession we might
>> need a queue of notifications so that we don't miss out on one widget
>> update because it was drowned
>> out by another.
>>
> 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.

Maybe the synths Sender subclass could handle this if it gets a notification
  - check with the other sender instances and decide whether it wants to
  send 2 controller changes or re-dump the patch or whatever.

> The only alternative I can think of is to defer the high-level layer, and
> instead try these tricks with individual synths.  After that, we can hunt
> for commonalities, and implement a higher-level layer.
>

Yeah no point implementing a high level layer until the low level details
are well understood by all involved - I probably haven't written enough 
drivers
yet to be an expert on flow control issues. But its definitely worth having
flow control in the back of our minds as we do other things.

My current plan of action is:
* M350 driver (nearly done)
* U220 driver (if I can work out what the manual is on about)
* Keystation Pro 88 driver
* Proteus 2000 family driver - this is a big one
Assuming I make it this far, then this might be the time when I would be 
ready to
think about rate limiting.

frankie