jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.

[Jsynthlib-devel] Some improvements

[<wi...@op...>]

Hello, due to the fact that I have some free time now I have decided to put some afford to make JSynthLib more handy for me. The first problem I have encountered was partial information about MIDI interfaces. It appears in JSynthLib Properties in MIDI and Synth Driver Panels. In MIDI Port combos there is only information about port number, namely Port 1, Port 2, and so on. It is confusing if the are more MIDI devices installed in a system, like in my case. I have changed the descriptions in the combos to contain also a device name. I wonder if  someone would see if it is worth putting into CVS. Files can be grabbed from http://jsynthlib.republika.pl/devnames_upd.zip The lines I have changed are marked with my name.

Robert Wirski

PS. There are more improvements I would like to make, for example:
- a patch in Scene/Library window should point to the same memory where it's came from, not to the first element in the combo list;
- there should be Scene templates;
Please, let me know If you have any ideas how to do it right before I make something incorrectly.

[Jsynthlib-devel] WG: Minimal update: Roland GP16

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

Hi at all,

I've got the following message from Mikael Kurula
the author of the Roland GP16 driver.

"Dear Joachim,

Sorry for contacting you directly, but I am not on the list anymore, and
I=20
saw your name in the source files.

I wrote the drivers for the GP16 a while ago, and to my great happiness,
I=20
today saw that they still work! So many thanks to the person who has
been=20
keeping them up to date! :)

However, I would like to replace the informational message to the one=20
attached. (It at least contains my current e-mail address.) I am almost=20
sure that I will have no time to fix the driver myself (there seem to be

some problems), but at least I feel that I should be reachable by any=20
interested person. Do you think it is of any interest to anyone if I
test=20
the driver and submit the bugreports e.g. to the development list? I=20
actually got an e-mail requesting the processor manuals a month ago, so
I'm=20
not the only person still using this processor. :)

This is probably old news, but the CVS did not work at all for me. I was

neither able to browse it online nor login. (The file I attach is from
the=20
0.20 jar file.)

Please feel free to contact me any time! :)

Best greetings,
Mikael"

Unfortunaly I'm currently not able to access the CVS server.
Can someone else please upload the new file?

Thanks in advance.

Best regards,
Joachim

[Jsynthlib-devel] JRE bug workaround in

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

Starting on line 411 in OberheimMatrixSingleEditor, there's a section
that works around some unspecified JRE bug:

>    if (Utility.getOSName().equals("Linux")) // Does J2SE 1.4 still
> require this?
>    {
>      ErrorMsg.reportStatus("Matrix1000Editor:  Linux Detected-- adding
> 30 pixels to window height to compensate for Sun/JRE bug");
>       Dimension rv = getSize();
>       setSize(rv.width, rv.height + 30);
>    }


I thought I saw some code working around a bug like this in the
JSLFrame/JSLDesktop infrastructure somewhere, but I can't find it at the
moment. Anyway, my questions are:
1 - Does this bug still exist in 1.4?
2 - If it does, wouldn't it need to be worked around for all JSLFrames
and, if so, shouldn't this code be in JSLFrame or JSLDesktop or
someplace like that?

- Joe

Re: [Jsynthlib-devel] Eclipse classpath broken

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

David A. Riggs wrote:
> The .classpath file in CVS references someone's C:\ drive for the
> location to the Groovy jar. The correct entry should be:
>
> <classpathentry kind="lib" path="groovy.jar"/>
I noticed that a few days ago, but didn't get around to fixing it at the 
time. I've fixed it now. Thanks.

- Joe

[Jsynthlib-devel] Eclipse classpath broken

[David A. R. <dav...@gm...>]

The .classpath file in CVS references someone's C:\ drive for the
location to the Groovy jar. The correct entry should be:

<classpathentry kind=3D"lib" path=3D"groovy.jar"/>


--
David A. Riggs <dav...@gm...>

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

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

Rib Rdb wrote:
> What do you mean "allow setting of the sysex data"
>   
Well, we kinda need some way for the actual sysex data to be put into 
(and retrieved from) a patch object, no? Right now, I think it's done in 
the actual implementations (for example, Patch.Patch(byte[] sysex) ), 
but it's not required by the interface itself. To move forward, we 
either need a way to get/set the sysex of a patch *or* we need a way for 
IPatch implementations to put the patch data in the set of properties 
they return.
>> Also, unless you like PropertyHolder, I'd prefer something a little
>> different. Maybe PropertySet or ValueSet. Or maybe you can suggest
>> something that you think sounds like what it does?
>>     
> How about importProperties( PropertyMap props )?
>   
One thing that dawned on me today was "We probably shouldn't use the 
word 'Properties', because Java already has a standard class called 
that, and this would confuse people because they'd think that our 
"Properties" had something to do with the standard Java "Properties".

However, just now, I realized... we *could* just use the plain Java 
Properties class, since it just is a String-to-String mapping. The 
thought I had was that I could extend Properties to something called, 
say, PatchProperties which would have the following additional 
functionality:
 1 - An exception or ErrMsg would be generated any time an existing 
property name was set (to catch cases where subclasses accidentally used 
a property name that was used by the superclass)
 2 - There'd be a set of convenience methods like getInt(String 
propertyName), getBoolean(String propertyName), setInt(String 
propertyName, int value), etc.

In this case, importProperties( PatchProperties props) and 
exportProperties( PatchProperties props) would be entirely appropriate.

- Joe

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

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

On 3/10/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> I have time to write the parser and the XML writer.... and I can write
> >> the PropertyHolder or whatever we want to call it. All you'd need to d=
o
> >> is support a read(PropertyHolder) and write(PropertyHolder) for any
> >> given patch in your XMLDriver code.
> >>
> > I shouild be able to do that.
> >
> So, to clarify then.... any implementation of IPatch would need to allow
> setting of the sysex data and then it should implement
> read(PropertyHolder) and write(PropertyHolder).

What do you mean "allow setting of the sysex data"

> Well, read and write are
> a little vague. How about something like importProperties and
> exportProperties? I would have suggested getProperties/setProperties,
> but getters usually return something and, in this case, we're going to
> want to give the class a PropertyHolder and then have it populate it.
>
> Also, unless you like PropertyHolder, I'd prefer something a little
> different. Maybe PropertySet or ValueSet. Or maybe you can suggest
> something that you think sounds like what it does?

How about importProperties( PropertyMap props )?

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

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

Rib Rdb wrote:
> On 3/9/06, Joe Emenaker <jo...@em...> wrote:
>   
>> I have time to write the parser and the XML writer.... and I can write
>> the PropertyHolder or whatever we want to call it. All you'd need to do
>> is support a read(PropertyHolder) and write(PropertyHolder) for any
>> given patch in your XMLDriver code.
>>     
> I shouild be able to do that.
>   
So, to clarify then.... any implementation of IPatch would need to allow 
setting of the sysex data and then it should implement 
read(PropertyHolder) and write(PropertyHolder). Well, read and write are 
a little vague. How about something like importProperties and 
exportProperties? I would have suggested getProperties/setProperties, 
but getters usually return something and, in this case, we're going to 
want to give the class a PropertyHolder and then have it populate it.

Also, unless you like PropertyHolder, I'd prefer something a little 
different. Maybe PropertySet or ValueSet. Or maybe you can suggest 
something that you think sounds like what it does?

- Joe

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

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

On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> Rib Rdb wrote:
> >>
> >>> The main reason IPatch was created was
> >>> so people don't have to subclass Patch.
> >>>
> >> "so people don't have to" make use of the existing code in Patch and,
> >> instead, have to write every method anew? Well, we shouldn't dwell on
> >> "how come it wasn't done *this* way?" stuff.
> >>
> >
> > "so people don't have to" be restricted by the design of the Patch clas=
s.
> >
> Well, I think Patch should have been a fairly minimal abstract class,
> and then SinglePatch and BankPatch would be subclasses of those with the
> Single- and Bank-specific methods... but I wasn't around when those
> decisions were made, and what's done is done. I'm just saying that there
> was a way to do it that didn't require every new type of patch to have
> to redefine all of the methods *and* which wouldn't overly restrict
> those new types of patches.
> >> This would allow us to change the format, or to
> >> support various formats. Even if we never decided to change the *file*
> >> format again, we could still use the PropertyHolder idea to support
> >> other formats for other purposes.... like transmission over the net or
> >> copy/paste or something like that.
> >>
> >
> > I guess I just prefer the extreme programming approach.  Why make it
> > more complicated now to support something that we might possibly want
> > to use at some point in the future.  I'd rather keep the design simple
> > now, and then when it needs to change, find the best design for the
> > new requirements.
> Well, that's how we got what we have now. Putting everything in core.*
> was a simple design that worked... until things started getting big. The
> current midi layer was a simple design that worked... until multiple
> things (like the midi monitor) needed to be notified of the same sysex
> messages. Now we have a half-dozen logging methods in MidiUtil and
> Actions all feeding into MidiMonitor, and they're getting called from a
> half-dozen other methods in PatchEdit and MidiUtil.
>
> Temporary fixes turn into permanent ones. Simple "just for now"
> solutions get appended to until they're unruly and unmanageable. So, the
> best way to save yourself grief down the road is to make sure that you
> design something now that isn't too complicated to use today, yet
> flexible to accommodate all the stuff you can imagine needing in the futu=
re.
> > But whatever.  I don't have time to write a new
> > parser and XML writer.  If you do, go right ahead.
> >
> I have time to write the parser and the XML writer.... and I can write
> the PropertyHolder or whatever we want to call it. All you'd need to do
> is support a read(PropertyHolder) and write(PropertyHolder) for any
> given patch in your XMLDriver code.

I shouild be able to do that.

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

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

Rib Rdb wrote:
> On 3/9/06, Joe Emenaker <jo...@em...> wrote:
>   
>> Rib Rdb wrote:
>>     
>>> The main reason IPatch was created was
>>> so people don't have to subclass Patch.
>>>       
>> "so people don't have to" make use of the existing code in Patch and,
>> instead, have to write every method anew? Well, we shouldn't dwell on
>> "how come it wasn't done *this* way?" stuff.
>>     
>
> "so people don't have to" be restricted by the design of the Patch class.
>   
Well, I think Patch should have been a fairly minimal abstract class, 
and then SinglePatch and BankPatch would be subclasses of those with the 
Single- and Bank-specific methods... but I wasn't around when those 
decisions were made, and what's done is done. I'm just saying that there 
was a way to do it that didn't require every new type of patch to have 
to redefine all of the methods *and* which wouldn't overly restrict 
those new types of patches.
>> This would allow us to change the format, or to
>> support various formats. Even if we never decided to change the *file*
>> format again, we could still use the PropertyHolder idea to support
>> other formats for other purposes.... like transmission over the net or
>> copy/paste or something like that.
>>     
>
> I guess I just prefer the extreme programming approach.  Why make it
> more complicated now to support something that we might possibly want
> to use at some point in the future.  I'd rather keep the design simple
> now, and then when it needs to change, find the best design for the
> new requirements.
Well, that's how we got what we have now. Putting everything in core.* 
was a simple design that worked... until things started getting big. The 
current midi layer was a simple design that worked... until multiple 
things (like the midi monitor) needed to be notified of the same sysex 
messages. Now we have a half-dozen logging methods in MidiUtil and 
Actions all feeding into MidiMonitor, and they're getting called from a 
half-dozen other methods in PatchEdit and MidiUtil.

Temporary fixes turn into permanent ones. Simple "just for now" 
solutions get appended to until they're unruly and unmanageable. So, the 
best way to save yourself grief down the road is to make sure that you 
design something now that isn't too complicated to use today, yet 
flexible to accommodate all the stuff you can imagine needing in the future.
> But whatever.  I don't have time to write a new
> parser and XML writer.  If you do, go right ahead.
>   
I have time to write the parser and the XML writer.... and I can write 
the PropertyHolder or whatever we want to call it. All you'd need to do 
is support a read(PropertyHolder) and write(PropertyHolder) for any 
given patch in your XMLDriver code.

- Joe

[Jsynthlib-devel] JGone

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

Hello all,

So, I've re-written the XMLFileUtils so that they don't require jdom.jar 
anymore. It seems to behave properly... so give it a try.

It appears that the XML file format is probably in flux right now as Rib 
and I figure out what we're going to do. So there will probably be a 
time in the future when JSL fails to read all of the XML files that it 
currently writes. This shouldn't be a problem, since it also saves to 
the old patchlib/scenelib serialized formats... but I just wanted 
everyone to know.

- Joe

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

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

On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> The default constructor is supposed to be called for all subclasses th=
at
> >> don't explicitly specify a super constructor in their own constructor.
> >> So, if I subclass Patch in a class called SpecialPatch and write:
> >>    public SpecialPatch() {
> >>      addPropertyName("SomeSpecialData");
> >>    }
> >>
> >> then the Author and Comment ones should still get put into the vector.
> >>
> >
> > Do you really think anyone is ever going to subclass Patch.
> I don't understand why Scene didn't, actually.

I don't know why it didn't originally, but if it used a subclass of
Patch then you couldn't have a scene containing XMLPatches

> > Have you seen how much of it is final?
> Well, that part's easy. You just delete the "final" part. :)

I would assume we put those there for a reason.

> > The main reason IPatch was created was
> > so people don't have to subclass Patch.
> "so people don't have to" make use of the existing code in Patch and,
> instead, have to write every method anew? Well, we shouldn't dwell on
> "how come it wasn't done *this* way?" stuff.

"so people don't have to" be restricted by the design of the Patch class.

> > I certainly like the idea of having a read method. But the parser I
> > wrote is event based (SAX), so a read method doesn't easily translate.
> > But I suppose we could make it work.
> >
> Well, it doesn't appear to me that our data format is going to require
> SAX and the "order-ness" that it provides. I mean, if the <Author>
> element comes before or after the <Sysex> element... what does it
> matter, as long as they all appear within the same <Patch> element?
> Furthermore, does SAX even have an easy system for writing the XML to a
> file? With DOM, you can read an XML into a Document and then save it
> write back out with a couple of lines of code.

I'm not saying we need sax.  I'm just trying to explain why I
suggested using setters instead of a single read method -- There's
already a parser in CVS that works that way.

> >> Lastly, the readProperty() method(s) should be really easy to write, s=
ince we can have the "xml." part of "xml.readProperty" holding the DOM Node=
 for just that patch... and readProperty could just turn right around retur=
n the value returned by "getAttribute()" for that node.
> >>
> > Do you mean to store all the data as attributes of an element instead
> > of children?
> Not necessarily. In fact, I was going to touch on that issue next.
> Although all of the data that's currently saved (except for sysex) is
> short enough for use as attributes, we wouldn't have control over
> subclasses (and/or future implementations of IPatch). So, we could
> either give the author a choice (like xml.writeElement() and
> xml.writeAttribute()) or just force everything to be an Element.
>
> I'm leaning toward just making everything an Element. Partly because you
> see to really want that and also because my next suggestion is that we
> make this whole thing not XML-specific. In other words, instead of a
>
>   void write(XMLWriter xml)
>
> method, it could be
>
>   void write(PropertyHolder props)
>
> and PropertyHolder (or... "PropertyBasket" if we want to use exiting JSL
> nomenclature :) ) would just hold all of the values that the patch
> object wanted to be saved. So, when a user clicks "Save" in JSL, JSL
> would...
>
>  1 - Create an empty DOM
>  2 - Get the next patch in the PatchBasket
>  3 - Create an empty "patch" DOM Element
>  4 - Create an empty PropertyHolder
>  5 - Call the patch's write(PropertyHolder) method with the new, empty
> one we just made
>  6 - Write those properties to the patch DOM Element
>  7 - Back to step 2
>
> The things to note here are that the patch classes would have no idea
> that we were using XML at all. Only the methods doing the actual
> save/load would know. This would allow us to change the format, or to
> support various formats. Even if we never decided to change the *file*
> format again, we could still use the PropertyHolder idea to support
> other formats for other purposes.... like transmission over the net or
> copy/paste or something like that.

I guess I just prefer the extreme programming approach.  Why make it
more complicated now to support something that we might possibly want
to use at some point in the future.  I'd rather keep the design simple
now, and then when it needs to change, find the best design for the
new requirements.  But whatever.  I don't have time to write a new
parser and XML writer.  If you do, go right ahead.

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

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

Rib Rdb wrote:
> On 3/9/06, Joe Emenaker <jo...@em...> wrote:
>   
>> The default constructor is supposed to be called for all subclasses that
>> don't explicitly specify a super constructor in their own constructor.
>> So, if I subclass Patch in a class called SpecialPatch and write:
>>    public SpecialPatch() {
>>      addPropertyName("SomeSpecialData");
>>    }
>>
>> then the Author and Comment ones should still get put into the vector.
>>     
>
> Do you really think anyone is ever going to subclass Patch.
I don't understand why Scene didn't, actually.
> Have you seen how much of it is final?
Well, that part's easy. You just delete the "final" part. :)
> The main reason IPatch was created was
> so people don't have to subclass Patch.
"so people don't have to" make use of the existing code in Patch and, 
instead, have to write every method anew? Well, we shouldn't dwell on 
"how come it wasn't done *this* way?" stuff.
> I certainly like the idea of having a read method. But the parser I
> wrote is event based (SAX), so a read method doesn't easily translate.
> But I suppose we could make it work.
>   
Well, it doesn't appear to me that our data format is going to require 
SAX and the "order-ness" that it provides. I mean, if the <Author> 
element comes before or after the <Sysex> element... what does it 
matter, as long as they all appear within the same <Patch> element? 
Furthermore, does SAX even have an easy system for writing the XML to a 
file? With DOM, you can read an XML into a Document and then save it 
write back out with a couple of lines of code.
>> Lastly, the readProperty() method(s) should be really easy to write, since we can have the "xml." part of "xml.readProperty" holding the DOM Node for just that patch... and readProperty could just turn right around return the value returned by "getAttribute()" for that node.
>>     
> Do you mean to store all the data as attributes of an element instead
> of children?
Not necessarily. In fact, I was going to touch on that issue next. 
Although all of the data that's currently saved (except for sysex) is 
short enough for use as attributes, we wouldn't have control over 
subclasses (and/or future implementations of IPatch). So, we could 
either give the author a choice (like xml.writeElement() and 
xml.writeAttribute()) or just force everything to be an Element.

I'm leaning toward just making everything an Element. Partly because you 
see to really want that and also because my next suggestion is that we 
make this whole thing not XML-specific. In other words, instead of a

  void write(XMLWriter xml)

method, it could be

  void write(PropertyHolder props)

and PropertyHolder (or... "PropertyBasket" if we want to use exiting JSL 
nomenclature :) ) would just hold all of the values that the patch 
object wanted to be saved. So, when a user clicks "Save" in JSL, JSL 
would...

 1 - Create an empty DOM
 2 - Get the next patch in the PatchBasket
 3 - Create an empty "patch" DOM Element
 4 - Create an empty PropertyHolder
 5 - Call the patch's write(PropertyHolder) method with the new, empty 
one we just made
 6 - Write those properties to the patch DOM Element
 7 - Back to step 2

The things to note here are that the patch classes would have no idea 
that we were using XML at all. Only the methods doing the actual 
save/load would know. This would allow us to change the format, or to 
support various formats. Even if we never decided to change the *file* 
format again, we could still use the PropertyHolder idea to support 
other formats for other purposes.... like transmission over the net or 
copy/paste or something like that.

- Joe

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

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

On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/8/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> Rib Rdb wrote:
> >>
> >>> I still think this has problems.  How do you handle transient data or
> >>> data which has multiple getters and setters?
> >>>
> >> Well, I think I hinted, at one point, at the idea of, instead of tryin=
g
> >> to autodetect the public getters and setters, maintaining an array or
> >> vector of the property names to save. For example, if the vector
> >> contained "Name", "Author", and "Date", then the XML load and save cod=
e
> >> would only try to call getName, setName, getAuthor, setAuthor, etc. Bu=
t,
> >> if my suggestions thus far have made you uncomfortable, then *this* id=
ea
> >> has probably got you squirming. :)
> >>
> >
> > Hmmm.  The more I think about it the more I like this idea.  It's more
> > uniform than having setters used for loading, but one method used for
> > writing.  We could add something like "List getXmlPropertyNames()" to
> > IPatch.  But then we still have the super problem.
> Well, yes and no. If the property names are kept in a vector or
> something similar, then the vector would be created in the base class
> and populated with some values via some add() method, like:
>    public Patch() {
>      addPropertyName("Author");
>      addPropertyName("Comment");
>      etc.
>    }

That would work, but that's probably something that should go in an
implementation not the actual interface.

>
> The default constructor is supposed to be called for all subclasses that
> don't explicitly specify a super constructor in their own constructor.
> So, if I subclass Patch in a class called SpecialPatch and write:
>    public SpecialPatch() {
>      addPropertyName("SomeSpecialData");
>    }
>
> then the Author and Comment ones should still get put into the vector.

Do you really think anyone is ever going to subclass Patch.  Have you
seen how much of it is final?  The main reason IPatch was created was
so people don't have to subclass Patch.  I think the main thing we
need to worry about is new implementations of IPatch (which are still
going to be rare and only done by people with an advanced knowledge of
JSynthLib), not subclasses of the existing two implementations.

> But now it's getting fairly cumbersome. We've got to have matching
> getters and setters, they have to be public, and their name has to match
> a String value in the PropertyName vector. So, at this point, I think it
> would then be easier to just use a special data structure for all data
> that we want to save (except the sysex. That's always special).
>
> How about this. Patch would have some object of Name/Value pairs which
> would contain all of the data that should be saved. This gets around all
> of the getters/setters. In fact, a class wouldn't have to change their
> code much at all. Things like:
>      patchName =3D getPatchNameFromSysexData();
> would become:
>     setValue("PatchName",getPatchNameFromSysexData());
>
> In support of this kind of method, I point out that the JAXP DOM stuff
> already has something like this in NamedNodeMap.
>
> The three problems I see with this are:
> 1 - The simple implementation I've proposed here only deals with
> strings. But there's nothing to keep us from making setIntValue(String
> name, int val), and setBoolVal(..) etc.
> 2 - There's nothing to purge old deprecated data. If Patch has a field
> called "Author" and then we decide, later, that we don't want an
> "Author" field anymore and strip any mention of it out of Patch, the
> Author data items already existing in XML files will continue to get
> loaded and saved.... even though they're never used by JSL. It's a weird
> version of a memory leak, if you will.
> 3 - Name collision. There's nothing to keep subclasses from stomping on
> values in the superclass. If you subclassed Patch, you'd need to know
> that Patch already uses "Author" so that you didn't try to use it
> yourself for a different purpose. Even worse, if we went in and added a
> property name to the Patch superclass, it could collide with a property
> name in one of Patch's subclasses.

I really don't like this idea.  And how do you enforce it with an
interface?  You would have to add getter and setter methods for this
data structure.  Read and write methods seems a lot simpler.

> > But as I said
> > before, I really don't think new Patch classes are going to be made
> > often, so we should just pick one.  And calling super.write seems more
> > like the java way to do it.  Java doesn't have much magic.
> >
> Well, if you don't feel like we're working our way any closer to a
> better solution, then we can just go with super.write().

Actually I meant super.getXmlPropertyNames.

> The one thing I'd want to change, however, is that I think we should have=
 a read()
> method as well. Here's why...
>
> The current "super.write()" proposal, as I understand it, is to have
> write() do things like:
>
>   xml.writeProperty("author", self.author);
>
> and then we need a setAuthor(String) method. I'm still wincing over the r=
equirement that "author" in the call to writeProperty match "setAuthor". Ho=
wever, if we had a read() method that did things like:
>
>   self.author =3D xml.readProperty("author");
>
> *then* we can put "author" in a constant, so we'd end up with code like t=
his:
>
>   private static final String AuthorXMLName =3D "author";
>
>   xml.writeProperty(AuthorXMLName, self.author);
>
>   xml.readProperty(AuthorXMLName);
>
> which is what you can see I did in my XMLFileUtils class. It makes it *mu=
ch* more likely that your IDE will catch any typos. Also, reading is done j=
ust like writing.

I certainly like the idea of having a read method. But the parser I
wrote is event based (SAX), so a read method doesn't easily translate.
 But I suppose we could make it work.

> Lastly, the readProperty() method(s) should be really easy to write, sinc=
e we can have the "xml." part of "xml.readProperty" holding the DOM Node fo=
r just that patch... and readProperty could just turn right around return t=
he value returned by "getAttribute()" for that node.

Do you mean to store all the data as attributes of an element instead
of children?  That sounds like a bad idea, and my parser certainly
won't be able to handle that.

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

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

Rib Rdb wrote:
> On 3/8/06, Joe Emenaker <jo...@em...> wrote:
>   
>> Rib Rdb wrote:
>>     
>>> I still think this has problems.  How do you handle transient data or
>>> data which has multiple getters and setters?
>>>       
>> Well, I think I hinted, at one point, at the idea of, instead of trying
>> to autodetect the public getters and setters, maintaining an array or
>> vector of the property names to save. For example, if the vector
>> contained "Name", "Author", and "Date", then the XML load and save code
>> would only try to call getName, setName, getAuthor, setAuthor, etc. But,
>> if my suggestions thus far have made you uncomfortable, then *this* idea
>> has probably got you squirming. :)
>>     
>
> Hmmm.  The more I think about it the more I like this idea.  It's more
> uniform than having setters used for loading, but one method used for
> writing.  We could add something like "List getXmlPropertyNames()" to
> IPatch.  But then we still have the super problem.
Well, yes and no. If the property names are kept in a vector or 
something similar, then the vector would be created in the base class 
and populated with some values via some add() method, like:
   public Patch() {
     addPropertyName("Author");
     addPropertyName("Comment");
     etc.
   }

The default constructor is supposed to be called for all subclasses that 
don't explicitly specify a super constructor in their own constructor. 
So, if I subclass Patch in a class called SpecialPatch and write:
   public SpecialPatch() {
     addPropertyName("SomeSpecialData");
   }

then the Author and Comment ones should still get put into the vector.

But now it's getting fairly cumbersome. We've got to have matching 
getters and setters, they have to be public, and their name has to match 
a String value in the PropertyName vector. So, at this point, I think it 
would then be easier to just use a special data structure for all data 
that we want to save (except the sysex. That's always special).

How about this. Patch would have some object of Name/Value pairs which 
would contain all of the data that should be saved. This gets around all 
of the getters/setters. In fact, a class wouldn't have to change their 
code much at all. Things like:
     patchName = getPatchNameFromSysexData();
would become:
    setValue("PatchName",getPatchNameFromSysexData());

In support of this kind of method, I point out that the JAXP DOM stuff 
already has something like this in NamedNodeMap.

The three problems I see with this are:
1 - The simple implementation I've proposed here only deals with 
strings. But there's nothing to keep us from making setIntValue(String 
name, int val), and setBoolVal(..) etc.
2 - There's nothing to purge old deprecated data. If Patch has a field 
called "Author" and then we decide, later, that we don't want an 
"Author" field anymore and strip any mention of it out of Patch, the 
Author data items already existing in XML files will continue to get 
loaded and saved.... even though they're never used by JSL. It's a weird 
version of a memory leak, if you will.
3 - Name collision. There's nothing to keep subclasses from stomping on 
values in the superclass. If you subclassed Patch, you'd need to know 
that Patch already uses "Author" so that you didn't try to use it 
yourself for a different purpose. Even worse, if we went in and added a 
property name to the Patch superclass, it could collide with a property 
name in one of Patch's subclasses.
> But as I said
> before, I really don't think new Patch classes are going to be made
> often, so we should just pick one.  And calling super.write seems more
> like the java way to do it.  Java doesn't have much magic.
>   
Well, if you don't feel like we're working our way any closer to a 
better solution, then we can just go with super.write(). The one thing 
I'd want to change, however, is that I think we should have a read() 
method as well. Here's why...

The current "super.write()" proposal, as I understand it, is to have 
write() do things like:

  xml.writeProperty("author", self.author);

and then we need a setAuthor(String) method. I'm still wincing over the requirement that "author" in the call to writeProperty match "setAuthor". However, if we had a read() method that did things like:

  self.author = xml.readProperty("author");

*then* we can put "author" in a constant, so we'd end up with code like this:

  private static final String AuthorXMLName = "author";

  xml.writeProperty(AuthorXMLName, self.author);

  xml.readProperty(AuthorXMLName);

which is what you can see I did in my XMLFileUtils class. It makes it *much* more likely that your IDE will catch any typos. Also, reading is done just like writing. Lastly, the readProperty() method(s) should be really easy to write, since we can have the "xml." part of "xml.readProperty" holding the DOM Node for just that patch... and readProperty could just turn right around return the value returned by "getAttribute()" for that node.

- Joe

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

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

On 3/8/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/8/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> True. Which is why I said "If any of those getters return anything oth=
er
> >> than String (or any other data types we know how to save and restore),
> >> then throw an exception, or fail, or complain, or do something". In
> >> other words, if the author added a getter like "Hashtable
> >> getHashtableofsomething()", then the XML saving code would throw up a
> >> warning message saying "Hey! We don't know how to save
> >> 'java.util.Hashtable', so you're going to lose the data returned by
> >> 'getHashtableofsomething()'!".
> >>
> >
> > I still think this has problems.  How do you handle transient data or
> > data which has multiple getters and setters?
> Well, I think I hinted, at one point, at the idea of, instead of trying
> to autodetect the public getters and setters, maintaining an array or
> vector of the property names to save. For example, if the vector
> contained "Name", "Author", and "Date", then the XML load and save code
> would only try to call getName, setName, getAuthor, setAuthor, etc. But,
> if my suggestions thus far have made you uncomfortable, then *this* idea
> has probably got you squirming. :)

Hmmm.  The more I think about it the more I like this idea.  It's more
uniform than having setters used for loading, but one method used for
writing.  We could add something like "List getXmlPropertyNames()" to
IPatch.  But then we still have the super problem.  But as I said
before, I really don't think new Patch classes are going to be made
often, so we should just pick one.  And calling super.write seems more
like the java way to do it.  Java doesn't have much magic.

> > Name has getters and
> > setters, but may also be stored inside sysex.
> Well, that's a device-specific trait, and it affects the current
> serialization method just as much as it would any new XML method. In
> other words, as JSL stands now, the "name" string is stored along with
> the sysex data and it's loaded with it, too. If individual driver
> classes choose to override getName and setName to access the sysex data
> directly and not use the "name" string, it shouldn't matter.
> > Sysex data can be
> > accessed as bytes or sysex messages, and now strings.  How do we
> > decide when to throw exceptions for unstorable data and which data
> > isn't supposed to be stored?
> >
> Well, if we didn't have a vector of properties to save, then we'd have
> to use matching pairs of public getters/setters.
> >> Now, I just thought of another way, which would use your "write()"
> >> methods without requiring super.write(). Using inspection, I think it
> >> *is* possible to make calls to the over-ridden methods of a superclass=
.
> >> In other words, the XML writing code could call a class' write(), and
> >> then call its superclass' write(), and then *that* superclass'
> >> superclass' write(), etc.... until it got all the way to the original
> >> class. But that's a little spooky.
> >>
> > Yeah.  And then you have problems if someone does call super.write().
> >
> Well, I knew that when I suggested it.... but it's not that big of a
> problem because you'd just get two copies of some data items and, at
> worst, it would just result in duplicate calls to setName, setWhatever...=
..
>
> You're starting to convince me that the super.write() method is the path
> of least resistance... but I *have* tried this very solution before and
> it looked great on paper and turned into a bit of a pain when it was put
> into practice. So, forgive me if I'm a little gun-shy about it.
>
> - Joe

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

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

Rib Rdb wrote:
> On 3/8/06, Joe Emenaker <jo...@em...> wrote:
>   
>> True. Which is why I said "If any of those getters return anything other
>> than String (or any other data types we know how to save and restore),
>> then throw an exception, or fail, or complain, or do something". In
>> other words, if the author added a getter like "Hashtable
>> getHashtableofsomething()", then the XML saving code would throw up a
>> warning message saying "Hey! We don't know how to save
>> 'java.util.Hashtable', so you're going to lose the data returned by
>> 'getHashtableofsomething()'!".
>>     
>
> I still think this has problems.  How do you handle transient data or
> data which has multiple getters and setters?
Well, I think I hinted, at one point, at the idea of, instead of trying 
to autodetect the public getters and setters, maintaining an array or 
vector of the property names to save. For example, if the vector 
contained "Name", "Author", and "Date", then the XML load and save code 
would only try to call getName, setName, getAuthor, setAuthor, etc. But, 
if my suggestions thus far have made you uncomfortable, then *this* idea 
has probably got you squirming. :)
> Name has getters and
> setters, but may also be stored inside sysex.
Well, that's a device-specific trait, and it affects the current 
serialization method just as much as it would any new XML method. In 
other words, as JSL stands now, the "name" string is stored along with 
the sysex data and it's loaded with it, too. If individual driver 
classes choose to override getName and setName to access the sysex data 
directly and not use the "name" string, it shouldn't matter.
> Sysex data can be
> accessed as bytes or sysex messages, and now strings.  How do we
> decide when to throw exceptions for unstorable data and which data
> isn't supposed to be stored?
>   
Well, if we didn't have a vector of properties to save, then we'd have 
to use matching pairs of public getters/setters.
>> Now, I just thought of another way, which would use your "write()"
>> methods without requiring super.write(). Using inspection, I think it
>> *is* possible to make calls to the over-ridden methods of a superclass.
>> In other words, the XML writing code could call a class' write(), and
>> then call its superclass' write(), and then *that* superclass'
>> superclass' write(), etc.... until it got all the way to the original
>> class. But that's a little spooky.
>>     
> Yeah.  And then you have problems if someone does call super.write().
>   
Well, I knew that when I suggested it.... but it's not that big of a 
problem because you'd just get two copies of some data items and, at 
worst, it would just result in duplicate calls to setName, setWhatever.....

You're starting to convince me that the super.write() method is the path 
of least resistance... but I *have* tried this very solution before and 
it looked great on paper and turned into a bit of a pain when it was put 
into practice. So, forgive me if I'm a little gun-shy about it.

- Joe

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

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

Rib Rdb wrote:
> On 3/7/06, Joe Emenaker <jo...@em...> wrote:
>   
>> Now, granted this is a problem that should only affect someone who's
>> authoring a subclass to a implementation of IPatch.... but the
>> combination of how easy it would be to forget to call super.write() and
>> the consequences for doing so...  well... they worry me.
>>     
>
> Any problem with serialization, no matter how it happens is going to
> cause problems until try to load it.
>   
Well, not necessarily. Before we save any data element to XML, we can 
make sure (at save time) that the proper method exists for putting that 
data back into the object. Of course, this doesn't guard against saving 
to XML, then removing the setter from the class, and then trying to load 
the XML. But I don't think there's *any* way to solve situations like that.
>> My rough idea of the introspection would work something like this:
>> - Get a list of all public getters and setters for the object...
>>     
>
> This has several problems.  For one, the XML setters are not normal
> setters: they have to take a string argument.
Well, at the present time, all fields of a patch that we're saving 
(except for the sysex itself) are strings. So, that's not a problem for 
the *present* situation. Now, as for the future, you pointed out that...
> Someone who just writes
> a patch class without knowing about serialization is probably not
> going to write this type of setter.
True. Which is why I said "If any of those getters return anything other 
than String (or any other data types we know how to save and restore), 
then throw an exception, or fail, or complain, or do something". In 
other words, if the author added a getter like "Hashtable 
getHashtableofsomething()", then the XML saving code would throw up a 
warning message saying "Hey! We don't know how to save 
'java.util.Hashtable', so you're going to lose the data returned by 
'getHashtableofsomething()'!".
> Also, you lose some flexibility.  For example the write method could
> do something like this
> if (xml.useGzip())
>   xml.writeGzippedProperty('gzippedSysex', this.sysex)
> else
>   xml.writeBinaryProperty('sysex', this.sysex)
>
> And the parser would automatically call the correct setter.  If
> getters and setters had to be paired, the getter would have to add
> some sort of a marker saying whether the data is zipped, and then the
> setter would have to split and switch based on that marker.
>   
On the other hand, you could have all gzipping done in the XML code. If 
a data element is gzipped, you add/change an attribute to the element. 
<sysex> or <sysex compression="none"> versus <sysex compression="gzip">. 
You can also set policies in the XML read/write code such as "gzip all 
String objects longer than 200 bytes". This way, authors of future patch 
classes don't have to brew their own compression/decompression stuff... 
and existing patch classes don't have to have the compression code 
retroactively added.

Now, I just thought of another way, which would use your "write()" 
methods without requiring super.write(). Using inspection, I think it 
*is* possible to make calls to the over-ridden methods of a superclass. 
In other words, the XML writing code could call a class' write(), and 
then call its superclass' write(), and then *that* superclass' 
superclass' write(), etc.... until it got all the way to the original 
class. But that's a little spooky.

- Joe

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

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

On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> Either of those solutions would require that the author of the subclas=
s
> >> have an awareness of the inner workings of the patch-saving system tha=
t
> >> I'm not convinced should be necessary.
> >>
> >
> > How is requiring a call to the super method an unreasonable awareness
> > of the inner workings?
> I didn't say that it was unreasonable... I just said that I'm not
> convinced that it should be necessary.
>
> The biggest problem I see is that, if you forget to call the
> super.write() method in your new class, then all of the superclass data
> isn't saved... and you don't discover it until you've closed the
> patchbasket and tried to reload it again.... at which point, the data is
> not coming back. In most other cases where you have to explicitly use
> the super prefix, its in the constructor, and forgetting to do so is
> usually immediately evident (due to thrown exceptions or a JFrame not
> actually getting instantiated... etc).
>
> Now, granted this is a problem that should only affect someone who's
> authoring a subclass to a implementation of IPatch.... but the
> combination of how easy it would be to forget to call super.write() and
> the consequences for doing so...  well... they worry me.

Any problem with serialization, no matter how it happens is going to
cause problems until try to load it.  By making it happen explicitly,
at least the author should know to look for problems there.

> >> I think we can find a slicker way.
> >>
> > Do you have any suggestions.  I think using introspection to find
> > which attributes to store would be more confusing to a driver author,
> > and very tricky to do correctly.
> >
> I'm not seeing how a driver author needs to be bothered with it.

Sorry, I meant patch author.

> My rough idea of the introspection would work something like this:
> - Get a list of all public getters and setters for the object and make a
> list that combines just the attributes that appear in both lists (so,
> the XML writer would then know all of the attributes that we can save
> now, and also set later in the object at the time we read the XML file).
> - If any of those getters return anything other than String (or any
> other data types we know how to save and restore), then throw an
> exception, or fail, or complain, or do something.
> - Get the data from the getters and save them to the XML.
>
> The benefits here are that, if you subclass an implementation of IPatch,
> it's harder to accidentally disrupt the saving of the data in the
> superclass. In fact, if the superclass declares its data, getters, and
> setters as final, then it might be *impossible* for you to mess it up.
>
> The downside is that the saving of the data just kinda happens "like
> magic". Once the author makes a public getter and setter for some piece
> of data, then it magically starts getting saved. In that respect, it's
> almost like it would be inventing an XML version of serialization.

This has several problems.  For one, the XML setters are not normal
setters: they have to take a string argument.  Someone who just writes
a patch class without knowing about serialization is probably not
going to write this type of setter.  I would think they would have a
harder time trying to find the problem than someone who write a write
method that didn't call super; at least this person would know the
problem is in their write method.
Also, you lose some flexibility.  For example the write method could
do something like this
if (xml.useGzip())
  xml.writeGzippedProperty('gzippedSysex', this.sysex)
else
  xml.writeBinaryProperty('sysex', this.sysex)

And the parser would automatically call the correct setter.  If
getters and setters had to be paired, the getter would have to add
some sort of a marker saying whether the data is zipped, and then the
setter would have to split and switch based on that marker.

> > This is just the simplest solution I could think of without writing a
> > new parser.
>
> Well, I'm all for that. In fact, our two proposals don't seem to differ
> in regards to how the XML gets read, parsed, and sets the values in the
> objects. I think we only differ on how we generate the XML at save time, =
no?

True.

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

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

Rib Rdb wrote:
> On 3/7/06, Joe Emenaker <jo...@em...> wrote:
>   
>> Either of those solutions would require that the author of the subclass
>> have an awareness of the inner workings of the patch-saving system that
>> I'm not convinced should be necessary.
>>     
>
> How is requiring a call to the super method an unreasonable awareness
> of the inner workings?
I didn't say that it was unreasonable... I just said that I'm not 
convinced that it should be necessary.

The biggest problem I see is that, if you forget to call the 
super.write() method in your new class, then all of the superclass data 
isn't saved... and you don't discover it until you've closed the 
patchbasket and tried to reload it again.... at which point, the data is 
not coming back. In most other cases where you have to explicitly use 
the super prefix, its in the constructor, and forgetting to do so is 
usually immediately evident (due to thrown exceptions or a JFrame not 
actually getting instantiated... etc).

Now, granted this is a problem that should only affect someone who's 
authoring a subclass to a implementation of IPatch.... but the 
combination of how easy it would be to forget to call super.write() and 
the consequences for doing so...  well... they worry me.
>> I think we can find a slicker way.
>>     
> Do you have any suggestions.  I think using introspection to find
> which attributes to store would be more confusing to a driver author,
> and very tricky to do correctly.
>   
I'm not seeing how a driver author needs to be bothered with it.

My rough idea of the introspection would work something like this:
- Get a list of all public getters and setters for the object and make a 
list that combines just the attributes that appear in both lists (so, 
the XML writer would then know all of the attributes that we can save 
now, and also set later in the object at the time we read the XML file).
- If any of those getters return anything other than String (or any 
other data types we know how to save and restore), then throw an 
exception, or fail, or complain, or do something.
- Get the data from the getters and save them to the XML.

The benefits here are that, if you subclass an implementation of IPatch, 
it's harder to accidentally disrupt the saving of the data in the 
superclass. In fact, if the superclass declares its data, getters, and 
setters as final, then it might be *impossible* for you to mess it up.

The downside is that the saving of the data just kinda happens "like 
magic". Once the author makes a public getter and setter for some piece 
of data, then it magically starts getting saved. In that respect, it's 
almost like it would be inventing an XML version of serialization.

> This is just the simplest solution I could think of without writing a
> new parser.

Well, I'm all for that. In fact, our two proposals don't seem to differ 
in regards to how the XML gets read, parsed, and sets the values in the 
objects. I think we only differ on how we generate the XML at save time, no?

- Joe

AW: [Jsynthlib-devel] Roland JD800 librarian and some comments

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

Hi Robert,

sorry, since yesterday I didn't had the time to add
your code to the JSynthLib CVS but it is now
included.

Cheers,
Joachim

PS: I think your english is ok (but I'm also no native speaker).

> -----Urspr=FCngliche Nachricht-----
> Von: jsy...@li...=20
> [mailto:jsy...@li...] Im=20
> Auftrag von wi...@op...
> Gesendet: Montag, 20. Februar 2006 12:38
> An: jsy...@li...
> Betreff: [Jsynthlib-devel] Roland JD800 librarian and some comments
>=20
> Hello,
> Roland JD800 librarian is ready and can be downloaded from=20
> www.jsynthlib.republika.pl/RolandJD800.zip. I would like also=20
> to share with you with my commentary on the JSynthLib.=20
> Firstly, I would like to propose to implement a function=20
> which allow us to create scene templates. I think there could=20
> be a button on a scene window like „save as=20
> template”, than we should be able to select „New=20
> Scene from template ...” from menu. It would save me a=20
> lot of time, really. I also wonder why single patch drivers=20
> do not allow to get edit buffers. It is my favorite type of=20
> work and saving edits to unit memories after every knob=20
> turning is tedious for me. I have included such an option in=20
> my JD800 driver. I understand that the JSynthLib uses edit=20
> buffers to examine/test patches only, so it would destroy the=20
> edits but it could be left up to a user to use such an option=20
> or not. Such things are found in commercial librarians (for=20
> example in SoundDiver) and I miss them a lo
>  t.
>  There is also a small comment on the driver=20
> „get” option. A Bank/Patch number in the=20
> scene/librarian window is not set to the value it comes from,=20
> just to the first field in the list. It should point to the=20
> same place by default.
> There is also an option which I dream about. The point is to=20
> have the ability to update a scene by pressing a button but=20
> also to revert to previous records, something like CVS. I=20
> have never seen such an option in any commercial librarian.
> Sorry for my English.
> Robert Wirski
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> dat=3D121642
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>=20

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

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

On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > Okay.  Let me explain a little about how the XML parser I built works.
> >  The basic idea is that has a list of element names which can have
> > child elements.  When it encounters the start tag for one of these
> > elements, it starts building an object.
> > So if there was an xml file like this:
> >
> > <patchbasket>
> > <patch>
> > <author>foo</author>
> > </patch>
> > </patchbasket>
> >
> There's some kind of patch data included, I hope. :) Sysex, maybe?

Of course.  I was keeping it a short as possible since this is just an
example of how the parser works.

> > The parser would:
> > 1) Create a patchbasket object
> > 2) create a patch object
> > 3) Use introspection to find (and call) a setter (in the patch)
> > setAuthor(String) or addAuthor(String)
> > 4) Use introspection to find (and call) a setter in the basket class
> > setPatch or addPatch which will accept the created patch
> > 5) Return the patchbasket object
> >
> Okay... this looks good.
> > Then each IPatch implementation has to have some sort of a
> > write method, plus matching setters.  We should probably have some
> > sort of helper for binary data.  The implementation would look
> > somthing like this:
> >
> > void write(XMLWriter xml) {
> >   xml.writeProperty("author", self.author);
> >   xml.writeBinaryProperty("data", self.sysex);
> > }
> >
> > void setAuthor(String author) { /* ... */ }
> > void setData(String data) { self.sysex =3D XMLTools.decodeBinary(data);=
 }
> >
> I'm a little uneasy by the requirement that the "author" in
> writeProperty has to match the "Author" in "setAuthor". First, you have
> to have two dissimilar items (a hard-coded string "something" in a call
> to writeProperty and a method called "setSomething") that have to match.
> Furthermore, if they don't match, your first indication of a problem
> comes *after* the XML file has been written and you're now trying to
> load it.
>
> The second problem is even worse, though. If *you* write an
> implementation of IPatch... then it would have a write() method. Now,
> suppose that *I* come along and write a subclass your implementation. If
> I want the additional data of my subclass saved, then I also have to
> have a write() method. However, if I do that, then *your* write method
> doesn't get called anymore. I'd either have to go look at your class and
> save all of the data elements that *your* write() method was saving
> (imagine what happens when you add/remove some data elements to your
> class without telling me), or I'd have to call "super.write(xml)" any
> time I wrote a write() method of my own.
>
> Either of those solutions would require that the author of the subclass
> have an awareness of the inner workings of the patch-saving system that
> I'm not convinced should be necessary.

How is requiring a call to the super method an unreasonable awareness
of the inner workings?  Isn't that sort of a standard practice?
Also, subclassing IPatch is something that is not done often and is
complicated. It already requires reading documentation to do it
properly.  So we can just add to the documentation explaining how the
write method has to work with the setters.

> I think we can find a slicker way.

Do you have any suggestions.  I think using introspection to find
which attributes to store would be more confusing to a driver author,
and very tricky to do correctly.
This is just the simplest solution I could think of without writing a
new parser.

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

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

Rib Rdb wrote:
> Okay.  Let me explain a little about how the XML parser I built works.
>  The basic idea is that has a list of element names which can have
> child elements.  When it encounters the start tag for one of these
> elements, it starts building an object.
> So if there was an xml file like this:
>
> <patchbasket>
> <patch>
> <author>foo</author>
> </patch>
> </patchbasket>
>   
There's some kind of patch data included, I hope. :) Sysex, maybe?
> The parser would:
> 1) Create a patchbasket object
> 2) create a patch object
> 3) Use introspection to find (and call) a setter (in the patch)
> setAuthor(String) or addAuthor(String)
> 4) Use introspection to find (and call) a setter in the basket class
> setPatch or addPatch which will accept the created patch
> 5) Return the patchbasket object
>   
Okay... this looks good.
> Then each IPatch implementation has to have some sort of a
> write method, plus matching setters.  We should probably have some
> sort of helper for binary data.  The implementation would look
> somthing like this:
>
> void write(XMLWriter xml) {
>   xml.writeProperty("author", self.author);
>   xml.writeBinaryProperty("data", self.sysex);
> }
>
> void setAuthor(String author) { /* ... */ }
> void setData(String data) { self.sysex = XMLTools.decodeBinary(data); }
>   
I'm a little uneasy by the requirement that the "author" in 
writeProperty has to match the "Author" in "setAuthor". First, you have 
to have two dissimilar items (a hard-coded string "something" in a call 
to writeProperty and a method called "setSomething") that have to match. 
Furthermore, if they don't match, your first indication of a problem 
comes *after* the XML file has been written and you're now trying to 
load it.

The second problem is even worse, though. If *you* write an 
implementation of IPatch... then it would have a write() method. Now, 
suppose that *I* come along and write a subclass your implementation. If 
I want the additional data of my subclass saved, then I also have to 
have a write() method. However, if I do that, then *your* write method 
doesn't get called anymore. I'd either have to go look at your class and 
save all of the data elements that *your* write() method was saving 
(imagine what happens when you add/remove some data elements to your 
class without telling me), or I'd have to call "super.write(xml)" any 
time I wrote a write() method of my own.

Either of those solutions would require that the author of the subclass 
have an awareness of the inner workings of the patch-saving system that 
I'm not convinced should be necessary.

I think we can find a slicker way.

- Joe

Re: [Jsynthlib-devel] Help building drivers: first steps

[Christoph E. <ce...@ch...>]

OK,

so the next questions. I have created an XML file for the Midisport 
globals first. It's attached, and I need some further explanation of 
the file. I have to understand it properly so I'll also be able to 
write the file for the 8 patchbay definitions.

Thanks & good night,


ce


======



<patch>
  <name>Midiman/m-audio Midisport 8x8 Global data</name>
  <group>
    <name>Header</name>
    <sysex>
      <name>Bulk Header</name>
      <!-- not yet sure what to put here -->
      <header>F0430.6B00000E0[8F]</header>
      <!-- Sysex header -->
      <constant>
        <name>Midiman ID</name>
        <default>0x00 0x01 0x05</default>
      </constant>
      <range>
       <!-- not yet sure what to put here -->
        <name>device Number</name>
        <min>0</min>
        <max>0x0F</max>
      </range>
      <constant>
      <!-- Find out which byte represents the model ID -->
        <name>Model ID</name>
        <default>0x6B</default>
      </constant>
      <constant>
        <name>Byte Count</name>
        <size>2</size>
        <default>0</default>
      </constant>
      <constant>
        <name>Address High</name>
        <default>0x0E</default>
      </constant>
      <range>
        <name>Address Mid</name>
        <min>0x08</min>
        <max>0x0F</max>
        <default>0x0F</default>
      </range>
      <range>
        <name>Address Low</name>
        <min>0</min>
        <max>0x7f</max>
      </range>
      <!-- End header -->
      <range>
        <name>Check-sum</name>
        <min>0</min>
        <max>0x7f</max>
      </range>
    </sysex>
  </group>
</patch>

Re: [Jsynthlib-devel] Help building drivers: first steps

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

Christoph Eckert wrote:
>> http://www.borg.com/~jglatt/tech/midispec/identity.htm
>>     
> Cool, never knew this before. Here's what I got:
>
> Sent:
> amidi -p hw:3,0,8 -S "f0 7e 7f 06 01 f7"
>
> Received:
> amidi -p hw:3,0,8 -d
> F0 7E 7F 06 02 00 01 05 00 00 04 00 01 00 21 00 F7  
>
> *Very* nice :) .
>   
Incidentally, you should also be able to do this in JSL. If you tell it 
to request/get a patch, and then select the "Generic" driver, you should 
be able to select an "Identity" patch. Then, you can "Edit" the identity 
patch and it should show you a hex dump of the response.

The gotcha is that I *think* you have to explicitly add an additional 
Generic device to your set of synthdrivers, because the first one (which 
is always there automatically) isn't included in many of the device 
drop-boxes.

- Joe