jsynthlib-devel

AW: [Jsynthlib-devel] Some questions about BankDriver

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

> Is there a=20
> way to do this?

Yes,

use
Thread.sleep
as you can see in my QuasimidiQuasarSingleDriver.

It helps much to look at other drivers.

Regards,
J. Backhaus

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...
> [mailto:jsy...@li...]Im Auftrag von Joe
> Emenaker
> Gesendet: Mittwoch, 11. Mai 2005 09:52
> An: JSynthLib Development
> Betreff: [Jsynthlib-devel] Some questions about BankDriver
>=20
>=20
> So... I just started trying to make a BankDriver, and I've got some=20
> questions.
>=20
> In this case, there's no way to request an entire bank. Instead, you=20
> have to issue a series of requests for individual patches.=20
> I'm sure that=20
> there are plenty of other devices like this.
>=20
> First question: Is there some way of "throttling" or flow-controlling=20
> the sending of requests. If I send out 100 single-patch requests all=20
> rapid-fire, the hardware device gets confused and doesn't end=20
> up sending=20
> 100 single patches. I need to send a request, wait for the patch to=20
> come, send another request, wait for the patch to come, etc.=20
> Is there a=20
> way to do this?
>=20
> Second question: Since my bank data is composed of multiple single=20
> patches, the bank data matches my sysexID from my=20
> SingleDriver. So, the=20
> banks are being recognized as single patches. Do I have to override=20
> acceptsPatch(Patch p) in my SingleDriver like:
>=20
>     boolean acceptsPatch(Patch p) {
>        return(super.acceptsPatch(p) && p.getMessages().length =3D=3D =
1);
>     }
>=20
> and do similar in the BankDriver? Is there an easier way? The=20
> patchSize=20
> variable would come in handy here, but the patches on this=20
> device vary=20
> in size.
>=20
> - Joe
>=20

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Joachim Backhaus wrote:

>>Is there a 
>>way to do this?
>>    
>>
>Yes,
>
>use
>Thread.sleep
>as you can see in my QuasimidiQuasarSingleDriver.
>  
>
Well, I was hoping for something a little better than Thread.sleep.

Thread.sleep requires a try/catch block, and it also requires you to 
wait *longer* than the time needed to transmit, in order to make sure 
you don't accidentally start the next transmission too soon.

Does anybody see any value in a method like:

    sendAndWait(SysexHandler h, int count, int timeout)

where the message would be sent, and wouldn't return until "count" new 
sysex messages had been received or "timeout" seconds (or milliseconds) 
had elapsed. If the timeout is reached, an exception would be thrown.

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Rib R. <ri...@gm...>]

That could be a possibility.  I think what we really need though is a
way for drivers to start receiving messages as they come in.  For
example, some synths (including the motif for some things) use a 2-way
communication protocol to transfer data. I don't think this type of
thing is currently supported by JSynthLib.

On 5/11/05, Joe Emenaker <jo...@em...> wrote:
> Joachim Backhaus wrote:
>=20
> >>Is there a
> >>way to do this?
> >>
> >>
> >Yes,
> >
> >use
> >Thread.sleep
> >as you can see in my QuasimidiQuasarSingleDriver.
> >
> >
> Well, I was hoping for something a little better than Thread.sleep.
>=20
> Thread.sleep requires a try/catch block, and it also requires you to
> wait *longer* than the time needed to transmit, in order to make sure
> you don't accidentally start the next transmission too soon.
>=20
> Does anybody see any value in a method like:
>=20
>     sendAndWait(SysexHandler h, int count, int timeout)
>=20
> where the message would be sent, and wouldn't return until "count" new
> sysex messages had been received or "timeout" seconds (or milliseconds)
> had elapsed. If the timeout is reached, an exception would be thrown.
>=20
> - Joe
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7393&alloc_id=3D16281&op=3Dclick
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Rib Rdb wrote:

>That could be a possibility.  I think what we really need though is a
>way for drivers to start receiving messages as they come in.  For
>example, some synths (including the motif for some things) use a 2-way
>communication protocol to transfer data. I don't think this type of
>thing is currently supported by JSynthLib.
>  
>
I looked at this closer last night and what I discovered confirms your 
suspicion.

Interestingly, if the messages were left in the sysexInputQueue for that 
driver's inport, then the driver *would* be able to get to them. 
However, the SysexGetDialog class regularly polls the queue and, 
apparently, steals the messages out of the queue to put in its *own* 
queue. This other queue, in SysexGetDialog doesn't appear to be 
accessible to the Driver subclasses.

The reason for this *seems* to be so that the SysexGetDialog can show a 
running count of the bytes received. However, there's no reason it can't 
do this while leaving the messages in the original queue.

Perhaps the messages should just be left in the original queue?

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Joe Emenaker wrote:

> ... the SysexGetDialog class regularly polls the queue and, 
> apparently, steals the messages out of the queue to put in its *own* 
> queue. This other queue, in SysexGetDialog doesn't appear to be 
> accessible to the Driver subclasses.
>
> The reason for this *seems* to be so that the SysexGetDialog can show 
> a running count of the bytes received. However, there's no reason it 
> can't do this while leaving the messages in the original queue.

I think I'm going to investigate implementing a "listener" system with 
the midi input queues.... where various parts of the program add 
themselves as "listeners" to be notified when a message comes in. Seems 
like a better way than to have SysexGetDialog running a timer to poll 
the inport.

Also, what does everyone else think about JSL being able to receive a 
patch even when the SysexGetDialog isn't open? For example, if JSL is 
just sitting there, and you dump a patch from a synth, it could pop up a 
message saying "JSL just received a patch dump which looks like a Alesis 
DM5 Bank. Would you like to save it in your current library or discard 
it?". Then, all the SysexGetDialog class would need to do is arrange to 
send out dump requests (and notify the receiving mechanism that a 
certain type of patch is expected).

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Rib Rdb wrote:

>On 5/14/05, Joe Emenaker <jo...@em...> wrote:
>  
>
>>I think I'm going to investigate implementing a "listener" system with
>>the midi input queues.... where various parts of the program add
>>themselves as "listeners" to be notified when a message comes in. Seems
>>like a better way than to have SysexGetDialog running a timer to poll
>>the inport.
>>    
>>
>That sounds good.  Perhaps each listener should also have a regular
>expression or something specifying which messages it wants to get.
>  
>
Well, I'm trying to do things the same way the JFC does things... and 
they usually do things like that with "filters". For example, go look at 
java.io.FileFilter. It's an interface with one method:
   boolean accepts(File f)
and then you can make your own filters, or use one of a few pre-made 
generic ones. So, I was thinking of making a pre-made filter which let 
you turn on/off the various classes of messages: PC, CC, sysex, note 
on/off, panic, etc.

However, there are two reasons I won't be doing that *quite* yet. First, 
my "QueueObserver" interface only notifies that a message was received 
and it lets you know which queu it came into. It doesn't give you the 
actual message. Second, it looks like the lowest-level sysex handlers in 
JSL immediate discard any non-sysex messages. This is why the 
MidiMonitor window never shows any CC's, PC's, etc.

>>Also, what does everyone else think about JSL being able to receive a
>>patch even when the SysexGetDialog isn't open? For example, if JSL is
>>just sitting there, and you dump a patch from a synth, it could pop up a
>>message saying "JSL just received a patch dump which looks like a Alesis
>>DM5 Bank. Would you like to save it in your current library or discard
>>it?". Then, all the SysexGetDialog class would need to do is arrange to
>>send out dump requests (and notify the receiving mechanism that a
>>certain type of patch is expected).
>>    
>>
>Would it even need to do the notification? We'd just need to make sure
>the incoming messages were routed correctly, wouldn't we.
>  
>
Well, I think that, from a user-experience point of view, you wouldn't 
want various sysex dumps just accumulating in your libraries. If the 
SysexGetDialog were open, then it could automatically insert them... but 
I think that, if you didn't have the dialog open, then you're not really 
"expecting" anything coming in, so it's probably nice to have JSL ask 
the user.

Of course, we could also make this an on/off option, where the user 
*could* decide to automatically accept incoming dumps.

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Rib Rdb wrote:

>On 5/14/05, Joe Emenaker <jo...@em...> wrote:
>  
>
>>Also, what does everyone else think about JSL being able to receive a
>>patch even when the SysexGetDialog isn't open? For example, if JSL is
>>just sitting there, and you dump a patch from a synth, it could pop up a
>>message saying "JSL just received a patch dump which looks like a Alesis
>>DM5 Bank. Would you like to save it in your current library or discard
>>it?". Then, all the SysexGetDialog class would need to do is arrange to
>>send out dump requests (and notify the receiving mechanism that a
>>certain type of patch is expected).
>>    
>>
>
>Would it even need to do the notification? We'd just need to make sure
>the incoming messages were routed correctly, wouldn't we.
>  
>
I've thought about it some more... and here's another idea of how the 
sysex input queues could work:
1 - A message comes into a given MIDI interface.
2 - The queue manager would get a list of all of the synthdrivers using 
that interface as the input (unless the user has selected to not use 
mutliple MIDI interfaces, in which case it gets a list of all of the 
synthdrivers).
3 - It checks to see if any of those synthdrivers recognize the patch 
*taking into account* the input interface and channel/deviceID of the 
patch versus that of the synthdriver.
4 - If it finds a perfect match, then it adds it to the current library. 
If it doesn't then it checks all of the synthdrivers to see if they 
recognize the patch *without* taking into account the input interface 
and channel/deviceID. If it *does* find a match this time, then there 
are a few possible reasons, which the user might want to choose between:
  A - This is a one-time patch dump from some device. Accept it and do 
nothing else.
  B - This is a dump from one of the hardware devices in the synthdriver 
list, but it has changed interfaces and/or channel/deviceID without that 
data being updated in JSL. Accept the patch *and* change the 
interface/channel/deviceID of the matching synthdriver to match that of 
the incoming patch.
  C - This is a dump from a new device. Accept the patch, and add a new 
device to the list of synthdrivers.
  D - Discard the patch entirely.

The nice thing is that "B" would be handy for handling problems where a 
misconfiguration is preventing any communication between JSL and the 
hardware device.

"C" would make it *super* easy to add new instruments to the list of 
synthdrivers *provided* that JSL could somehow go through all of the 
available drivers... not just the ones in the users list of configured 
ones. If it did this, imagine how easy this would be for new users. 
Basically, they could run JSL, plug their MIDI interface into something, 
do a patch dump from it, and JSL would magically configure the driver 
for it. It would make it pretty difficult to *not* have success with JSL.

Just a thought.

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Rib R. <ri...@gm...>]

One of the reasons I was thinking about filters is so that drivers
could accept messages that aren't part of a patch. For example, when
sending a patch to the synth a driver could register that it's
expecting a patch dump succeeded or patch dump failed message. In this
case it might also be useful to specify how long a filter would last -
ie "I'm only expecting one message like this, and I want to give up
after 30 seconds"

On 5/14/05, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
>=20
> >On 5/14/05, Joe Emenaker <jo...@em...> wrote:
> >
> >
> >>Also, what does everyone else think about JSL being able to receive a
> >>patch even when the SysexGetDialog isn't open? For example, if JSL is
> >>just sitting there, and you dump a patch from a synth, it could pop up =
a
> >>message saying "JSL just received a patch dump which looks like a Alesi=
s
> >>DM5 Bank. Would you like to save it in your current library or discard
> >>it?". Then, all the SysexGetDialog class would need to do is arrange to
> >>send out dump requests (and notify the receiving mechanism that a
> >>certain type of patch is expected).
> >>
> >>
> >
> >Would it even need to do the notification? We'd just need to make sure
> >the incoming messages were routed correctly, wouldn't we.

> Well, I think that, from a user-experience point of view, you wouldn't
> want various sysex dumps just accumulating in your libraries. If the
> SysexGetDialog were open, then it could automatically insert them... but
> I think that, if you didn't have the dialog open, then you're not really
> "expecting" anything coming in, so it's probably nice to have JSL ask
> the user.

Good point. I didn't think about that


> I've thought about it some more... and here's another idea of how the
> sysex input queues could work:
> 1 - A message comes into a given MIDI interface.
> 2 - The queue manager would get a list of all of the synthdrivers using
> that interface as the input (unless the user has selected to not use
> mutliple MIDI interfaces, in which case it gets a list of all of the
> synthdrivers).
> 3 - It checks to see if any of those synthdrivers recognize the patch
> *taking into account* the input interface and channel/deviceID of the
> patch versus that of the synthdriver.
> 4 - If it finds a perfect match, then it adds it to the current library.
> If it doesn't then it checks all of the synthdrivers to see if they
> recognize the patch *without* taking into account the input interface
> and channel/deviceID. If it *does* find a match this time, then there
> are a few possible reasons, which the user might want to choose between:
>   A - This is a one-time patch dump from some device. Accept it and do
> nothing else.
>   B - This is a dump from one of the hardware devices in the synthdriver
> list, but it has changed interfaces and/or channel/deviceID without that
> data being updated in JSL. Accept the patch *and* change the
> interface/channel/deviceID of the matching synthdriver to match that of
> the incoming patch.
>   C - This is a dump from a new device. Accept the patch, and add a new
> device to the list of synthdrivers.
>   D - Discard the patch entirely.
>=20
> The nice thing is that "B" would be handy for handling problems where a
> misconfiguration is preventing any communication between JSL and the
> hardware device.
>=20
> "C" would make it *super* easy to add new instruments to the list of
> synthdrivers *provided* that JSL could somehow go through all of the
> available drivers... not just the ones in the users list of configured
> ones. If it did this, imagine how easy this would be for new users.
> Basically, they could run JSL, plug their MIDI interface into something,
> do a patch dump from it, and JSL would magically configure the driver
> for it. It would make it pretty difficult to *not* have success with JSL.

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Rib Rdb wrote:

>...it might also be useful to specify how long a filter would last -
>ie "I'm only expecting one message like this, and I want to give up
>after 30 seconds"
>  
>
I think this is doable. There's already a "getMessage(int timeout)", so
we could make a "getMessage(MidiMessgageFilter filt, int timeout)".

However, things are getting a little odd as I'm looking at the low-level
midi code in JSL.

First off, MidiUtil is the second-largest file in core.*, at 33K. I
think it's a good candidate for being broken up into smaller classes,
because it's doing a lot of loosely-related things. One of its duties is
managing all of the sysex input queues (ie, arranging to have the JVM
deliver all incoming messages to the various queues, etc), and I think
all of that can be broken off into a "InputQueueManager" or something.

But that's not the scary part. The scary part is this. When MidiUtil
receives a SysexMessage object from the JVM, it puts it in the queue,
waiting for some part of JSL to come claim it. The problem is that these
SysexMessage objects from the JVM might *not* be complete sysex
messages, since large sysex messages can get broken up into smaller
chunks for transmission (with the device I was testing my code with, the
sysex dump was getting broken into two chunks). When this happens, I
think I recall that all but the last message has the 0xF7 stripped.

This causes a problem because, from the looks of it, MidiUtil leaves
these messages separated in the queue, and only combines them into a
single SysexMessage when you actually call getMessage(). Because they
aren't combined before then, my new code (which notifies various
"listeners" or "observers" about new messages when they arrive) ends up
notifying the listeners *multiple* times for each *complete* sysex message.

I'm thinking that a modest re-write of the input-queue parts of MidiUtil
is in order... especially since there are several comments in
getMessage() like "// THIS IS NOT CORRECT BEHAVIOR. !!!FIXIT!!!". There
are also some other practices in MidiUtil.getMessage() that aren't
really ideal. For example, if you call getMessage() and only the first
part of a long sysex message is in the queue, then it goes into a loop
where it checks for the rest of the sysex message every 10ms for
anywhere from 1s up to 10s.

I'm pretty sure that I can overhaul this and make it pretty slick,
without all of this 10ms looping, and, in the process, put in support
for MidiMessageFilters and reception of messages other than sysex ones.
However, this code in MidiUtil is so rough around the edges, that I'm
afraid that there might be synthdrivers which have coded around some of
its bugs.... and that "fixing" MidiUtil might break something else.

But I gotta try....

- Joe

Re: AW: [Jsynthlib-devel] Some questions about BankDriver

[Joe E. <jo...@em...>]

Joe Emenaker wrote:

>I'm pretty sure that I can overhaul this and make it pretty slick,
>without all of this 10ms looping, and, in the process, put in support
>for MidiMessageFilters and reception of messages other than sysex ones.
>  
>
Well, it turned out to be easier than I had feared. I've now got a midi
input queue system that doesn't have to do any polling. The queues
notify any observers as messages come in. It will be easy, from here, to
add support for midi message filters on a per-observer basis, so we
could do things like... let the MidiMonitor be notified of all messages,
yet let SysexGetDialog only be notified of sysex messages, etc.

Another thing I plan to do soon is to add a "thru-filter". I'm currently
experimenting with a rackmount effects unit which seems to merge all
incoming messages through the out. So, when I request a patch from the
unit, the first thing I get back is the request I sent. I think I'm
going to have the midi sender keep a rotating queue of, say, the last 5
or so messages it sent out. If something comes in which exactly matches
it, it could be ignored.

- Joe