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

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

On 04/09/2011 23:33, Joe Emenaker wrote:
> 308 JSynthLib.1051/JSynthLib/core/MidiUtil.java
>
>
> I'm a little surprised that so few lines have been altered. I'm also 
> surprised that MidiUtil is the top of the list, but I just looked at my 
> copy and I now remember that I've made the whole thing its own process 
> thread which dispatches MIDI messages to the appropriate driver, etc. 
>

Is this thread separation only for receiving messages, or is it also for
sending messages? Both the current TX81Z driver and my planned Proteus
2000 series driver look like they may need some kind of asynchronous
sending mechanism so I've been thinking of how best to achieve this.

The TX81z seems to have a hardware limitation whereby an error message
can appear on its screen talking about its midi message buffer being
full. I am assuming this is because there needs to be some kind of rate
limit on messages sent to it.

The Proteus 2000 seems to have very long single patch dumps - 2k+! The
Proteus 2000 provides 2 transfer mechanisms - one  where you just send
it blind, and another where there is some handshaking. So the Proteus
driver could just send the patches in the blind method, which might be
ok for 1 patch, but I shudder to think about sending an entire bank of
patches that way without flow control! So to do a good job on the driver
I think it will need to support handshaking.

While I could imagine implementing the TX81z flow control as a generic
mechanism that could apply to various drivers (a simple setting each
could set), the P2k handshaking protocol maybe doesn't lend itself to a
generic implementation.

I wonder if there are any other drivers that use some kind of flow
control or rate limitation mechanism (beyond freezing the UI for a few
ms! ).

frankie