Re: JSL 1.0 and 2.0 (Re: [Jsynthlib-devel] Anyone here ever used any other librarian programs?)

[Hiroo H. <hir...@co...>]

Joe> Perhaps we should start compiling a "wishlist" of changes that we'd li=
ke=20
Joe> to see for version 2. What are all of the things that people would hav=
e=20
Joe> liked to have, but could not because of file format limitations?

The below is a mail I wrote before.  Any text format is fine.  I'm
proposing XML just because we don't have to reinvent a wheel by using
existing libraries.

Joe> Also, is there any reason why we couldn't provide a converter (which=
=20
Joe> would have the old classes in their old locations) to convert from the=
=20
Joe> current format to some new one?
Do you have any good way to solve the problem?


Forwarded by Hiroo Hayashi <hir...@co...>
----------------------- Original Message -----------------------
From:    Hiroo Hayashi <hir...@co...>
To:      jsy...@ya...
Date:    Fri, 05 Mar 2004 00:59:56 -0600
Subject: Re: [jsynthlib-dev] encoding for xml driver
----

Hi,

I tried to mean that hash is used by editor internally, and byte array
is used outside of editor (sending/receiving or saving/loading patch).=20
We need only one set of conversion method.

JSynthLib can use a patch name which is independent from the real
patch name used by synth.  Patch name used by synth is not long enough
and machine dependent.  For example the data format for JSynthLib can be;

<patch>
  <name>Drum kit for combo jazz with dark sizzle ride symbal</name>
  <file>RolandTD6_0012.syx</file>
  ...
</patch>=20

There are some more merits.  We can use any length of patch name and
non-ascii characters for patch name.  The patch name used by synth is
one of parameter which editor can edit.  We can specify a name for a
bank patch of which a synth cannot have a name.  Librarian does not have
to know anything about the patch format.  XML is not a good language for
binary data (patch data). Binary data is saved in a standard binary file
(raw binary file).  The binary file can be used by other software tools
(ex. cat XXX >/dev/midi :-)).

Rib>> In either way XML driver have to encode to or decode from byte
Rib>> array.  I understand "1" means that XML driver keeps the state
Rib>> of all parameters in byte array and every time it access one of
Rib>> parameters, it have to do conversion.  And "2" or "3" keeps the
Rib>> state of palates in natural format, and conversion is done only
Rib>> before send (or save) patch and after receive (or load) patch.

=2E..

Rib> A hash is a very good idea!  However, I hadn't thought about saving.=
=20
Rib> It seems like we wouldn't want to save these hash maps, but we do
Rib> want to save the information like which patch class handles the patch
Rib> data, and what data goes in which message for a multi-message patch.=
=20
Rib> Also, the librarian only needs to be able to access the name of the
Rib> patch.  The other parameters are only accessed from the editor.=20
Rib> Maybe the XML driver should have two patch classes - one that stores
Rib> the byte arrays and knows how to en/decode the name for the library
Rib> and another that stores all the info in a map that's only passed to
Rib> the editor.  This way the user doesn't have to wait for possibly
Rib> thousands of parameters to be decoded just to change the name. Both
Rib> would follow the same interface, so nothing but the driver really
Rib> should need to know that this was going on.
--=20
Hiroo Hayashi

--=20
Hiroo Hayashi