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

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

On 09/08/11 16:01, Joe Emenaker wrote:
> On 9/8/2011 2:31 AM, frankster wrote:
>> 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.
> I'm thinking this:
> - There should be a application-wide rate limit on how often widgets
> send updates when the user is moving them. This limit would be able to
> be set by the user. It would *always* send when the user releases the
> widget, but they could also ask for updates to be sent X times per
> second... or whenever the control has moved another X% of the entire
> range since the last send.
This sounds reasonable.
> - Widgets would be ignorant of any rate limit imposed by the individual
> synths. The MIDI layer would know about them, and it would queue up and
This is a sensible division of responsibility I think.
> throttle outbound messages. If the outgoing queue ever got too full (ie,
> we don't want the MIDI layer queuing up 30 seconds of widget updates),
> then it would throw some exception. The widgets would decide how to deal
> with the exception. They could just discard the latest update they
> wanted to send, or they could possibly tell the MIDI layer something
> like "Discard all of the pending updates from me that you've got queued,
> and just send this one".

What about if the midi layer will never queue more than 1 message from a 
particular widget (so the midi layer would have to track the source of 
each message) and if multiple messages appeared from the same widget's 
Sender class, it would discard all but the most recent.

This would mean that widget messages have to be stateless and 
interchangeable. Is this a reasonable condition? It is on the 
synths/drivers i've played with but I can't speak for most of them.

frankie