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

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

Brian wrote:

>>
>> So... what happens if the world, someday, comes up with MIDI2 with 
>> some new sysex begin/end bytes instead of F0/F7? We go back and 
>> rewrite all of the drivers?
>
> No. That would be unnecessary. Even if someday MIDI2 comes out, all 
> existing synths will still be using MIDI1, so all existing drivers 
> will work fine.

Well, imagine if MOTU then came out with a MIDI2 version of their 
MidiExpress split/merge box.... and you've got all of your synths 
plugged into that. Suppose, also, that the box had a "feature" that 
reformatted all old-style sysex messages into newfangled (ie, using 
something other than F0/F7) new-style ones. Then, you'd have legacy JSL 
drivers receiving patches from legacy hardware... but with new-style 
messages coming into JSL.

Granted... it's a *completely* contrived scenario... and it will 
probably *never* happen. But my point is this: sysex is a *transfer* 
protocol. It's a way of getting a data payload between two devices. 
Drivers should concern themselves with the payload, not with how it 
arrived.... because it causes unnecessary work for everybody and it 
makes it hard to adapt to future protocols. If it came in by midi (with 
F0/F7) or my carrier-pigeon or through morse-code on a telegraph, most 
drivers don't need to see the F0 and F7.

For a real-world example, tell me how many of JSL's current synthdrivers 
set their "sysexID" variable to a string that does NOT begin with "F0"? 
I haven't stumbled across any yet. In fact, how many deviate from the 
"[F0][ManufacturerID][DeviceID][payload][F7]" format? Every device I 
currently own conforms to this message style. Yet, every JSL driver has 
to manually craft sysex messages itself. How many of the current 
drivers, do you estimate, all have an, essentially, identical bit of 
code in createNewPatch which takes the data of the patch and just slaps 
the F0 and the manuf and device ID's on the beginning and the F7 on the end?

> ... we ran into problems with some synths that would send dumps like 
> this:
>
> <JSynthLib sends Request Dump Message>
>
> Symth Sends Back:
>
> C0 0 0 FF FE F0 .  .  .  .F7 FE FE C0 0 0, etc.
>
> If we treat the entire string as a patch and save it, when we try to 
> load it back to the synth, the synth will not understand it.
> We have to extract the "Sysex" part of the midi stream from the rest 
> of the stream.

Right! JSL asked for a sysex message, and that's all that it grabs off 
of the wires. What I'm getting at is that, a vast majority of the time, 
JSL might as well lop the F0 and the F7 and give the driver the stuff 
inside.

Well... getting back to my original problem, it turns out that the 
reason I couldn't edit the patch was exactly the reason most people 
suggested: the sysex message that I made in createNewPatch didn't match 
what I set sysexID to. Since I, personally, don't anticipate ever 
writing a driver that creates patches that it doesn't recognize (duh!), 
I don't see a reason why createNewPatch shouldn't use sysexID as the 
header of the sysex message in the patch. That way, it would be 
impossible to create a patch that didn't get an affirmative response 
from acceptsPatch() (or whatever that method is).

What I ultimately did is made a subclass of Driver called LDDriver that 
just lets me set the manufacturerID and deviceID strings. Then, my 
*real* driver is a subclass of *that*, which only worries about the 
actual payload of the sysex message. When createNewPatch() is called in 
LDDriver, it gets the data payload from the subclass, an then slaps the 
F0, the manufID, and devID on the front and the F7 on the end. 
editPatch() will strip the same stuff *off* before passing it on to the 
subclass. So now... the actual driver subclass merely sets the manufID 
and devID in the constructor and then just worries about the data payload.

Why am I telling you this? I'm not sure. I doubt anybody else is going 
to use it because it's not the established JSL way. I guess I'm just 
hoping that somebody else will see that doing it this way is A) simpler 
and less prone to mistakes, and B) applicable to probably 75% or more of 
the devices we'll come across (and the remaining 25% are still free to 
use subclass Driver directly).

Anyway... the nice doctors with their scalpels are at the door now, so 
I'll stop complaining and conform now..

- Joe