[Jsynthlib-devel] XML Library format (was: Roland MT32 files ready ...)

[Joachim B. <jba...@pi...>]

Hi,

> 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".=20

hmm, maybe we should change core.Patch because sooner or later
this will lead to confusions.

I haven't looked deeper, but as far as I can see changing
this and the corresponding getter and setter methods to
"field1" and "field2" should be relatively easy with Eclipse.

I can do that if no one disagrees.

So to avoid confusion I suggest to re-name "author" "field1"
and "date" "field2" in the XML format.
If real "author" and "date" fields are required later,
we can easily add them.

What do the others think about that?

> It's not very fancy, so far.

I like simple things. :)

Regards,
Joachim

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von Joe Emenaker
> Gesendet: Dienstag, 11. Oktober 2005 03:39
> An: jsy...@li...
> Betreff: Re: AW: [Jsynthlib-devel] Roland MT32 files ready=20
> for inclusion in JSynthLib source tree
>=20
> Joachim Backhaus wrote:
>=20
> >>I made some non-trivial changes to the code that interacts=20
> >>with it (so=20
> >>that it can also load XML libraries if it needs to), and I haven't=20
> >>tested my changes very thoroughly.
> >>   =20
> >>
> >Sounds interesting but I think we should wait for the "core"=20
> developers
> >to state their opinion (a week or so?).
> >
> >How does the XML format look like?
> >Can you post an example?
> > =20
> >
> Here's an excerpt from one of my libraries:
>=20
> > <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> > <patchlib>
> >   <patch author=3D"" date=3D"" comment=3D"Probably a Alesis=20
> Patch, Size: 7431">
> >     <patchData>8AAADgUAAB1PN0AgDgYCQQAwEAQAcDEcDCcLCWBTOH9+...
> >       ...KQABf2J/f3Qvf39Ff394X39/fg/3</patchData>
> >   </patch>
> >   <patch author=3D"" date=3D"" comment=3D"Probably a Roland=20
> Patch, Size: 18108">
> >     <patchData>EEEQADASAAAAAAAAPwEGAAQBAAABAQYGBgMDAwMDAwMDA...
> >        ....AMyLX8ACAsAACwBFkb3</patchData>
> >   </patch>
> >   <patch author=3D"Patch A1 & A2" date=3D"Studio Voc"=20
> comment=3D"Probably a
> > DOD Electronics Patch, Size: 1786">
> >     <patchData>8AAAEAAkQgAYAQAUABBHAG9pbmcg...
> >          ...fw5PZH48OSMTeH8OTwNkfjkj9w=3D=3D</patchData>
> >   </patch>
> >   <patch author=3D"Factory 1, 2, & 3" date=3D"Studio Voc"
> > comment=3D"Probably a DOD Electronics Patch, Size: 2679">
> >     <patchData>8AAAEAAkQgAYAQAUABBTAHR1ZG...
> >       =20
> ...H4PYAN4Wj8CD2B+D2BvE3h/Dk9kfjw5IxN4fw5PA2R+OSP3</patchData>
> >   </patch>
> > </patchlib>
>=20
> 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".=20
> 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=20
> 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=20
> fields later,
> then we can add them in and let LibraryFrame. The "comment"=20
> 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=20
> store it this
> way than to try to allow each device class or driver to=20
> 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=20
> store the
> sysex data and, instead, stored values that the driver=20
> derived from the
> data... and if there ended up being a bug in the driver, then=20
> 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=20
> or bank on
> it).
>=20
> It's not very fancy, so far. However, is *is* storing all=20
> data in every
> Patch object within a library, so it's not "incomplete", either.
>=20
> - Joe
>=20