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

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

On 9/9/2011 1:56 AM, William Zwicky wrote:
> We could let each synthdriver decide their own queue policy (ie, only
>> hold one message per widget, or hold all of them). A more-complicated
>> solution would be for widgets to indicate which messages belong as a
>> set... but I don't see a need for that.
>>
> I think my example above matches that last case.  Once the message for
> widget A has started sending, other messages can be queued, but they can't
> be sent until widget A says 'handshake complete'!

My initial reaction to this is that this isn't an issue with the rate of 
data sent by the MIDI layer, so the MIDI layer shouldn't be involved. 
I'm thinking that the synthdriver should be able to manage all of this 
itself. The only reason we'd need to trouble the MIDI layer with this is 
if your synthdriver either needed special transfer-rate limits *or* if 
your synthdriver needed to block all traffic for *other* synths on that 
interface while the communication were happening. Otherwise, this should 
be able to be managed by the synthdriver.

> Finally, I'd like to vote against the user rate-limit option that was
> proposed earlier.  Rate limiting is not a real feature, it's a workaround to
> cope with flaky synths.  And these workarounds should be properly researched
> and coded in the driver so that the user doesn't need to worry about it at
> all.  It *might* be useful as an emergency feature to cope with situations
> the developer didn't discover, but it should *not* be part of the normal
> operation of JSynthLib.

Okay... just so we're clear, you're referring to *user* rate-limit. The 
idea of the end user being able to determine how often widgets send 
updates to the synth, right? But raw data throughput limiting in the 
MIDI layer is still a useful feature?

- Joe