Re: AW: AW: [Jsynthlib-devel] Okay... so why can't I edit a patch with this?

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

Brian wrote:

> Originally, JSynthLib didn't track MidiIn ports for each device. Only 
> the recieve window even dealt with MidiIn. So when you did a patch 
> receive you would give the port you wanted to receive on, and then 
> would always have to do the dump manually from the synth. You would 
> see bytes received and when you knew the dump was done, hit OK. At 
> that point JSynthLib would look for a matching driver.
>
> This was improved upon greatly several versions back by having 
> JSynthLib track a MidiIn for each synth and to request patch dumps by 
> selecting a Driver rather than a port. Now we know in advance what 
> type of patch we are getting. So the question then, can we figure a 
> way to let the driver say, "This is enough, this patch is complete" So 
> we don't have to count on the user to tell us?

My kneejerk idea to solve this would be to let the driver return a 
boolean (false="I need more messages to complete this", true="The 
current set of sysexes you gave me are a complete patch") when JSL 
offers it a patch/message. The problem, however, is that the method used 
to "offer" the message to a driver is "acceptsPatch", isn't it? And that 
*already* returns a boolean. So, unless you want it to return a 
tri-state (0=no, 1=need more messages, 2=yes).... then you might need to 
add a second method, like "acceptsPatchWithMore". So, if a driver is 
offered a message (or set of messages) which look like a good start, but 
aren't complete, would return *false* to acceptsPatch, and *true* to 
acceptsPatchWithMore. Then, JSL would just cycle through the drivers 
calling acceptsPatch and, if it got no takers, would try them all again 
with acceptsPatchWithMore. Then, you just have Driver default to return 
false for acceptsPatchWithMore and those with a need would override it.

However, you then have a potentially sticky issue with the possibility 
of other sysex messages getting mixed in with your patch dump. For 
example, let's say that you start a multi-message dump from a synth and 
then, somehow, you start a dump from *another* synth. They could get 
intermingled and then you'd have a situation where a string of messages 
are being collected for a synth and then... suddenly, the deal is 
off.... the driver is now returning false from acceptsPatchWithMore.

> Anyone willing to take a look into this. We also need to make sure to 
> divorce the receive dialog from the actual recieve logic. We need to 
> be able to call a Get function from anywhere, not just the dialog. 
> Something lke

Normally, I would. I like refactoring and cleaning existing code. I 
think I like it even more than writing *new* code, but I'm currently 
busy teaching myself how to write a driver right now. :)

I do have one question though. If I tell JSL to get a patch from a synth 
and a patch from something *else* comes in, does JSL still cycle through 
all of the current drivers (or all of the ones on that channel) calling 
acceptsPatch, or does it only check it for the driver it's expecting one 
for? Also, what's the spec'd behavior in this case?

- Joe