AW: AW: [Jsynthlib-devel] Joe's changes to MidiUtil

[Joachim B. <jba...@pi...>]

Hi,

I think I remember the discussions about the=20
"sleep" solution and I like your solution,=20
if it really works. ;-)
If it is also compatible with the old way I think
it's ok to commit the changes to CVS with the
prior CVS tagging that Bill mentioned.

Bugs will be found and fixed. :-) (Hopefully ;-) ).

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Joe Emenaker
> Gesendet: Dienstag, 11. Oktober 2005 00:02
> An: jsy...@li...
> Betreff: Re: AW: [Jsynthlib-devel] Roland MT32 files ready=20
> for inclusion in JSynthLib source tree
>=20
> Joachim Backhaus wrote:
>=20
> >>2 - I've also changed the way sysex messages are delivered to the=20
> >>drivers. I think that this new design is much better and more=20
> >>flexible.... but, again, my *implementation* of it might have=20
> >>some bugs.
> >>   =20
> >>
> >
> >Can you explain the changes a bit deeper?
> > =20
> >
> Well, I'll explain the problem I had to solve, first.
>=20
> I was writing a bank-driver for a device and it turned out=20
> that I had to=20
> request a bank from the device by requesting each of the individual=20
> patches individually. This presented timing issues because, if I=20
> requested the next patch before the last one was done=20
> sending, the patch=20
> data could get interrupted, etc.
>=20
> So, I needed to do something in my bank driver like:
>=20
>   for(int i=3D0; i<patches; i++) {
>     send( /* sysex bytes to request patch # i */ );
>     sleep( some number of milliseconds );
>  }
>=20
> This isn't a good solution, because the sleep time has to be=20
> made long=20
> enough to accomodate the worst-case scenario. So, it ended up=20
> resulting=20
> in some long waits while I received a bank.
>=20
> The reason for all of this seems to be due to how=20
> SysexGetDialog works.=20
> It sends the sysex request, and then starts polling MidiUtil to keep=20
> track of the bytes received. Then, when the user presses "Done", then=20
> SysexGetDialog tries to deliver the sysex message(s) to the driver.
>=20
> In my opinion, there are three problems with this:
> 1 - The driver doesn't get updates as sysex data is coming in=20
> (to allow=20
> the driver to send the request for the next patch immediately=20
> after the=20
> last one came in).
> 2 - Polling is wasteful.
> 3 - An additional problem is that MidiUtil only seems to make *sysex*=20
> messages available to the rest of the parts of JSL...=20
> stripping out all=20
> other midi messages. This limits the usefulness of MidiMonitor.
>=20
> What I did was change MidiUtil so that any other class could=20
> ask to be=20
> notified when any complete midi message was received. This=20
> way, multiple=20
> parts of JSL (SysexGetDialog, MidiMonitor, individual drivers, etc)=20
> could request to be notified when a message was received.=20
> Additionally,=20
> each "listener" could specify a filter (much like how=20
> java.io.FilenameFilter works) which would let them specify which=20
> messages they were notified of (which would allow MidiMonitor to give=20
> the user checkboxes to enable/disable note-on/off, CC, PC,=20
> etc. messages.
>=20
> Because this makes the midi message delivery within JSL more=20
> efficient=20
> and flexible, I was able to do things like giving the=20
> individual synth=20
> drivers access to a progress bar in SysexGetDialog, so that it could=20
> accurate represent how much of the patch/bank request was complete.
>=20
> - Joe
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,=20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20