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

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

On 08/09/2011 06:54, William Zwicky wrote:
> On Wed, Sep 7, 2011 at 6:28 AM, frankster <jsy...@te...>wrote:
>
>> On 09/06/11 19:15, Joe Emenaker wrote:
>>> Oooh. A rate-limited "sendSysex()" or something could be a good addition.
>> It might need to be a little more complicated than just sendSysex(),
>> because I think the UI controls could send quite a lot of messages out
>> if you changed them quite frequently.
>>
> I worry that for some synths, the rate limiting is synth-specific.  Is there
> (or are you thinking of) a framework to plug rate limiting into?  Or would
> we need to implement a layer on top of sendSysex()?

Maybe the Sender base class that we already use with the widgets can do
this for us without having
to write plugins (just have each driver register a max amount per time
frame it can handle).
For example if we have something centrally tracking the rate of data
that has recently been sent to a
device or a midi port (and each driver can register how much data in
what time frame its device can handle),

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.

Can anyone think of anything simpler that would do the job? Although one
advantage of this is that it would
keep the driver simple, and all the complexity would be in core base
classes.

>
> As for UI controls, we definitely need a smart system for that.  If the user
> drags a slider from 0 to 100, we don't want to send 100 updates, just the
> few we actually have time for.

yeah my tx81z definitely can't handle all these ui events and I don't
think the TC M350 can either even though
its much more modern. ;) Should have the driver ready for this later
tonight actually

frankie