Re: AW: [Jsynthlib-devel] Roland MT32 files ready for inclusion in JSynthLib source tree

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

Joachim Backhaus wrote:

>>I made some non-trivial changes to the code that interacts 
>>with it (so 
>>that it can also load XML libraries if it needs to), and I haven't 
>>tested my changes very thoroughly.
>>    
>>
>Sounds interesting but I think we should wait for the "core" developers
>to state their opinion (a week or so?).
>
>How does the XML format look like?
>Can you post an example?
>  
>
Here's an excerpt from one of my libraries:

> <?xml version="1.0" encoding="UTF-8"?>
> <patchlib>
>   <patch author="" date="" comment="Probably a Alesis Patch, Size: 7431">
>     <patchData>8AAADgUAAB1PN0AgDgYCQQAwEAQAcDEcDCcLCWBTOH9+...
>       ...KQABf2J/f3Qvf39Ff394X39/fg/3</patchData>
>   </patch>
>   <patch author="" date="" comment="Probably a Roland Patch, Size: 18108">
>     <patchData>EEEQADASAAAAAAAAPwEGAAQBAAABAQYGBgMDAwMDAwMDA...
>        ....AMyLX8ACAsAACwBFkb3</patchData>
>   </patch>
>   <patch author="Patch A1 & A2" date="Studio Voc" comment="Probably a
> DOD Electronics Patch, Size: 1786">
>     <patchData>8AAAEAAkQgAYAQAUABBHAG9pbmcg...
>          ...fw5PZH48OSMTeH8OTwNkfjkj9w==</patchData>
>   </patch>
>   <patch author="Factory 1, 2, & 3" date="Studio Voc"
> comment="Probably a DOD Electronics Patch, Size: 2679">
>     <patchData>8AAAEAAkQgAYAQAUABBTAHR1ZG...
>        ...H4PYAN4Wj8CD2B+D2BvE3h/Dk9kfjw5IxN4fw5PA2R+OSP3</patchData>
>   </patch>
> </patchlib>

A few things about this:
1 - There are attribute values named "author" and "date". This is what
they are called in core.Patch. However, in the LibraryFrame, they were
apparently changed at some point to "Field1" and "Field2". So, what the
*user* sees as "Field1" and "Field2" are actually held in the "author"
and "date" strings in core.Patch.  One of the nice things about XML
(over serialization) is that we can add/remove fields at any time... and
we can give them whatever names we want. So, I decided to name these
"author" and "date", and if we want other, generic comment fields later,
then we can add them in and let LibraryFrame. The "comment" attribute is
the same as the comment in LibraryFrame.
2 - The patchData element holds the actual sysex data, in BASE64
encoding. This is for two reasons. First, it's simpler to store it this
way than to try to allow each device class or driver to define their own
XML tags (like <equalizerMidGain>, <LFO1freq>, etc). Second, and
more-importantly, is that the actual physical device is the *ultimate*
authority regarding the correctness of the data. If we didn't store the
sysex data and, instead, stored values that the driver derived from the
data... and if there ended up being a bug in the driver, then we'd have
no way of getting the pristine data (unless we could get access to the
physical device again, and if the device still had that patch or bank on
it).

It's not very fancy, so far. However, is *is* storing all data in every
Patch object within a library, so it's not "incomplete", either.

- Joe