Re: [Jsynthlib-devel] Re: patchlib file format (was JSL 1.0 and 2.0)

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

I like the look of this.

Since this format would support multiple patches in a single file... 
would we want to *use* that capability, or would we keep all of the 
patches separate?

Bill Zwicky wrote:

> Hey looky, I have two cents too!  Here's my suggestion:
>
> <patchlib>
>  <patch synth="CZ" name="fatlottagood">
>    <description>sounds like that sound from the song about the people 
> .. y'know the one</description>
>    <field1>CZ401A</field1>
>    <field2>CZ401.SYX</field2>
>    <field name="author">Mr. Bill</field>
>    <data>
>      6238768263917634762873
>      7169374619384612387468
>      1349061032964912734883
>    </data>
>  </patch>
>  <etc./>
> </patch>

...

> <data> can be base 16 or 64 or something, and is generated by the 
> Driver superclass.

Since the data encoding is something which pertains the using XML files, 
I think that the code for is should be in the XML routines and not in 
the Driver system.

Also, I've come across binary data encoded in XML before, so I don't 
know if there's a standard for it or if everyone just creates their own 
solution. If we have to implement our own, we should see if there's a 
MIME64 encoder/decoder either in the foundation classes or freely available.

> Sub-classes can override and provide a human-readable XML element tree 
> if they really want.

I'm a little uneasy about the idea of having any XML-awareness in the 
synthdrivers.

> Converting from the old format is easy.  It's a serialized object 
> stream, right?  We can create a converter that deserializes the file, 
> then produces the new object model on command.

I agree. We already have all of the code to read the current format in 
the current JSL. All we need to do is make the code to write the *new* 
format (which we'd have to do anyway) and hook them together.

- Joe