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

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

Bill Zwicky wrote:

>> Why not just let the XML routines get a list of an editor's 
>> ParamModels? It should be able to learn everything it needs from that 
>> in order to generate the XML.  Keep in mind that one possible problem 
>> with not storing the original sysex data is that some parts of a 
>> sysex dump aren't spec'd and can't be changed. 
>
> Can ParamModels be grouped or nested?

If they can't, I think that they should. That way, you could create sets 
of ParamModels which depend upon other settings (ie, if 
Effect=="Flanger", then use ParamSetA, if Effect=="Chorus", use 
ParamSetB, etc.). But that's probably for a later discussion.

> Perhaps there needs to be a higher level element that describes a 
> "blank" sysex with these unchangable bits filled in.  Or alternately, 
> a constant, non-editable ParamModel that provides these bytes.

That's a thought. Something like ConstantParamModel or something.

>> Overall, I see this as being of marginal value. What's the point of 
>> editing the XML by hand? 
>
> *The* point of XML is data exchange and (to a lesser degree) 
> hand-editing.  If we don't need either feature, then why do we need to 
> change the save format at all?

I don't think that hand-editing was much of the idea. To me, XML's 
strength is the fact that its universal enough so that it's easy to get 
a parser for it, yet you can easily specify its format in a way that a 
universal parser can understand. A result of this is that you can alter 
the format in many ways which: 1) are compatible with previous formats 
of the XML files or your own code, and 2) don't require any modification 
of the parser.

For example, what if Brian, someday, decided that having a "Field1" and 
"Field2" was too limiting and wanted to add a "Field3"? Using the 
current format, I imagine that we'd have to alter our code to detect if 
we were reading an older format file and, if so, read it in the old way, 
etc. It could be done.... but it probably wouldn't be pleasant. On the 
other hand, if it were in XML, all we'd have to do is add a Field3 to 
the doctype-definition and then have our code look for it.

The *main* reason for changing the format seems to be that the current 
format uses serialization or something which is preventing us from 
moving the stuff in core.* into nice, separate packages. I'm guessing 
that there are also a few extra things that people would like to see 
added to the format but weren't worth changing the format for by 
themselves. Now, if we *do* change the format, my vote (and it seems the 
vote of many) is for XML. The reason *I* would like to use it is because 
it would be easy for use to ammend the format later without causing any 
upheaval.

- Joe