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

[William Z. <wrz...@po...>]

On Thu, Sep 8, 2011 at 8:54 AM, Joe Emenaker <jo...@em...> wrote:

> On 9/8/2011 8:13 AM, frankster wrote:
> > 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 strikes me as a great way to do it. We could even do it without the
> widget losing its place in the queue. We could just replace the old
> message with the new one.
>

That actually sounds pretty decent.  But what if my synth won't tolerate a
queue? i.e. Maybe I need to strictly control the ordering of messages, or
maybe the synth won't accept the second message until the first message has
properly completed all handshaking.

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'!

Maybe we need lockSynth() and unlockSynth() to block the queue until some
code is complete.  And if the synth is really flaky, lockBus() and
unlockBus() to prevent other messages from confusing the synth.

Speaking of lockBus(), I believe this only needs to block transmission to
synths downstream (i.e. farther from the computer) from the flaky synth, as
upstream synths will not pass thru messages targeted at themselves.  Are
there any synths that pass thru all their own messages?  Do we need an API
to flag synths that behave in non-standard ways?

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.

-Bill Zwicky