Re: [Jsynthlib-devel] XML patch saving....

[Rib R. <ri...@gm...>]

I just glanced at the code.  It looks like you're casting everything
in the PatchBasket to Patch.  That won't work with the XML driver (or
any other custom Patch classes).  It looks like a simple solution for
doing the output would be to make IPatch extend
org.jsynthlib.utils.Writable, and use org.jsynthlib.utils.XMLWriter
instead of the JDOM XMLOutputter.  Then each patch implementation only
needs to add a write method.

Reading the XML files back in is more complicated, because the parser
needs to know what it should do with the elements it gets (either call
a setter method with the string contents, or build an object, then
call a setter).  This probably means we need to decide on some
restrictions on how patches can store themselves.  Perhaps something
like:
<patchlib type=3D"scene, library, etc">
  <patch type=3D"classname">
    <author>Whatever</author>
    <!-- and other string values as determined by the implementation -->
   <!-- or sub patches for bank patches -->
  </patch>
</patchlib>

On 2/22/06, Joe Emenaker <jo...@em...> wrote:
> As the first step toward getting the classes refactored into a sane
> package hierarchy, I have committed my changes to support saving patches
> to XML.
>
> Here's the rundown:
>  o For the time being, I'm using the jdom.jar library.... so you'll need
> to add jdom.jar to your classpath. Just look for any place where you
> have "groovy.jar" and change it to either "groovy.jar; jdom.jar" or
> "groovy.jar:jdom.jar". I don't remember if the "colon vs. semicolon"
> thing is platform-dependent.
>
>  o Whenever you save any library (*just* libraries.... I haven't done
> scenes, yet), they are saved as the original "something.patchlib" file
> as well as "something.patchlib.xml".
>
>  o When you load a file, you'll still be loading the original
> ".patchlib" versions of your library. To change this, you need to open
> AbstractLibraryFrame and look for "void open(File file)". In that
> method, you'll see two boolean values: "readXMLFile" and "readOldFile".
> IF YOU MAKE BOTH OF THESE TRUE, YOU'LL GET TWO COPIES OF EACH PATCH! I
> did this so that you can load both versions at the same time and then
> open them both in a patch editor and see if there is any difference.
> Just be warned, however, that if you *save* the library after that, both
> the .patchlib and the .patchlib.xml will now have duplicates. So, if you
> load, save, load, save, etc. with both booleans set to "true", your
> library will double each time, and it will get really big really fast. I
> learned this the hard way. :)
>
>  o The patch data is compressed via gzip and then converted to base64
> and then saved in the XML file. As a result, I've seen the XML file be
> anywhere from 10% to 50% the size of the .patchlib.
>
> =3D=3D=3D=3D Things to think about while trying this =3D=3D=3D=3D
>
>  o Right now, so that the XML file is closely associated with the
> .patchlib file, I've named it .patchlib.xml. What extension do we want
> to have permanently?
>
> - Joe
>
>
>