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

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

On 09/09/11 15:40, Joe Emenaker wrote:
> On 9/9/2011 7:17 AM, frankster wrote:
>> On 09/09/11 15:03, Joe Emenaker wrote:
>>> On 9/9/2011 1:56 AM, William Zwicky wrote:
>>>> 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.
> Well, that's a different case (but it's one that we've still discussed,
> and I think there does need to be a way for a synthdriver to tell the
> MIDI layer "I can't handle more than X bytes per second... no matter
> *what* synth it's for, so don't let any data onto the wires faster than
> that"). What *Bill* seems to be referring to is that there seems to be a
> synth which requires an orchestrated series of messages for updating
> synth settings. For example:
>
> Where I imagine most synths use self-contained messages, like:
> Msg: Update parameter 27 to value 10
> Msg: Update parameter 27 to value 12
> Msg: Update parameter 27 to value 14
>
> Bill seems to have a synth which requires something like:
>
> Msg: Begin messing with parameter 27
> Msg: Set parameter to value 10
> Msg: Set parameter to value 12
> Msg: Set parameter to value 14
> Msg: Done messing with parameter 27
>
> You can see how things would get messed up if there was a second "begin"
> message before the "end" message for the first.
>
> So, my point was that this kind of awareness of the *context* (not the
> data-rate) of the messages is probably best kept in the synthdrivers.
>
ah ok i was getting confused with the other situation

frankie