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

[Brian <br...@ov...>]

>
> 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?


Alot  do, actually a lot of synths have pretty complex "Default 
Patches", so the drivers actually store a dump of a "Default Patch" in a 
file and load it in when create new patch is performed.

>
> 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.

I dunno. Some synths have a patch dump made up of multiple F0..F7 pairs. 
For example, the Boss DR-660 Driver, a patch is actually i think 14 
sysex messages sent in quick succession. Lopping off the first and last 
byte but leaving the
others in place would be kind of odd and it would be a nightmare to have 
to insert a bunch of F0 and F7's all throughout the patch in order to 
send or receive data. Especially since not all the sub-messages have a 
fixed size.

> 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).


I appreciate what you are trying to do, but belive me, you are making 
things much harder on yourself by doing this. This kind of thing always 
seems like it would be simpler, but it ends up causing problems. There 
are many different interfaces and API's JSynthLib has to support for 
patches. In every case, whenever I tried to design something clever to 
make driver writing easier, it ended up making things more complicated 
because some synth manufacturer did some attrocious thing with their 
sysex spec. I think It's easier to tell a driver writer, whatever 
bizzare data your manufacture prepends to the patch, insert that here... 
and have it always work, then have to explain put your manufactuer ID 
here, your device ID here, this is the standard sysex
representation of that data, if your synth doesn't use that than 
subclass this instead.... True it would make it a tiny bit easier in 75% 
of the cases, but it would make things a nightmare for the other 25%.

Please understand that we have an "established JSL way" not because we 
want to be subborn or because we want to make your life more difficult 
but because our way works for all supported synths. Collectively, we 
have written
driviers for over fify synthesizer models. The interfaces and paradigms 
evolve over time as one after another any pleasing abstraction we use 
gets smashed by some amazingly atrocious sysex spec which goes ahead and 
does something completely incompatable with our assumptions and 
abstractions. In truth, I fear any abstraction at a higher level than "A 
patch is an array of bytes." Is going to be violated by some as of yet 
unsupported synth.

Plus I would hate to write an editor where I had to worry that what the 
manual was calling byte number 55, was actually byte number 48 in the 
array I was passed because some stuff had been stripped off the front.

That said, it is a good idea to look back occasionally at what has 
evolved and look to see if it can be refactored without losing anything. 
We've been doing this for quite some time. If you think the current 
source is driving you insane,
go find a copy of version 0.16.  Helper classes which make the common 
case easier to implement are a *good thing* as long they are easy and 
intuitive to work around in the (unfortunately all to common) case where 
a synth spec
refuses to cooperate. One example of this, is that we provide a default 
"Compute Checksum" method so that many synths don't have to implement it 
themselves, but if (again all to commonly) the synth uses some other 
approach to
checksum computation or even uses multiple checksums (again way too 
common), the author can override this. I don't think that having to 
subclass a different version of driver just to work around some simple 
thing is viable.

Brian