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

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

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.

==== Things to think about while trying this ====

 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