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

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

On 09/09/11 15:03, Joe Emenaker wrote:
> 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.

I think it does concern the midi layer because transmitting data to one 
synth could overload a different synth on the same port. Although we can 
expect a synth driver to know how much traffic its device can handle, we 
can't expect a synth driver to care or know about other synths. So it 
could make sense for the midi layer to have the ability to enforce the 
lowest common denominator throughput if required.

I would think drivers would need to be able to specify a maximum number 
of bytes to occur in a specified timeframe. But maybe for a driver the 
problems occur only while processing large sysex messages, in which case 
maybe it would need to lock its port for e.g. 30ms after sending a message.

frankie