Re: [Jsynthlib-devel] Changes to the GenericDevice

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

On 2/5/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
>
> >I don't really remember this discussion, but your description of data
> >models sounds exactly like the Decoders used by the current XML
> >driver.  Perhaps we should find a way to combine the two ideas instead
> >of having two next-generation classes trying to accomplish the same
> >thing.
> >
> >
> Well, I'll tell you the things that I was trying to "fix" at the time,
> and you can tell me how much it matches what your decoders do.
>
> 1 - Just about every sysex message I've seen from a MIDI device has been
> of the form "0xF0 [manufacturerID] [deviceID] ... 0xF7". I find it a
> little strange that every synthdriver has to handle stripping/ignoring
> these bytes on incoming data and replacing them on outgoing data. I felt
> that each driver should be able to just set some manufacturerID and
> deviceID static variables and then some common code in JSL would handle
> stripping/replacing these automatically. For non-conforming MIDI
> devices, it would still be possible to access the raw patch data.

The XML driver automatically takes care of the 0xF0 at the beginning
and the 0xF7 at the end.  Synth drivers still have to handle the
manufacturer id, but if this is standard enough I suppose we could
change that.  Even so, it's not that hard to do.  For the Motif it
amounts to this:
      <constant>
        <name>YAMAHA ID</name>
        <default>0x43</default>
      </constant>
      <range>
        <name>device Number</name>
        <min>0</min>
        <max>0x0F</max>
      </range>
      <constant>
        <name>Model ID</name>
        <default>0x6B</default>
      </constant>


> 2 - Some synths use 8-bit data for their patch data, and then encode it
> into 7-bits *only* for transmission via the MIDI interface. So, before
> the synthdriver can do anything interesting with the data (ie, look up
> the patch names, edit patch data, etc), it first has to turn the 7-bit
> data back into 8-bit data (and it must do the reverse of this before it
> sends the data back out over the MIDI interface). Since it's tricky to
> write the encoders/decoders for this properly (and also since
> manufacturers, Alesis, for example, tend to use a certain encoding on
> multiple devices), it would be nice if we had a few classes that handled
> the most-common encoding methods.

This is what decoders are for.  They handle encoding and decoding
simple values as well as things such as signed numbers, strings, and
large numbers. Currently there are big and little endian versions of
decoders for synths that send data in either 4 or 7 bit chunks.

> 3 - Same goes for checksums.

There is also a Checksum class for this.  There is a BasicChecksum
which does a simple sum, but is designed to be easily subclassed for
implementing most other types of checksums.

> With just these three issues addressed, it's my hope that a beginner
> synthdriver author would be able to get started with a synthdriver very
> rapidly. For example, imagine some code like this:
>
> public class MyNewSynthDriver extends NextGenDriver {
>   static int manufacturerID =3D 0x41; // Roland
>   static int modelID =3D 0x001B; // GT-3
>   static dataModel =3D new BossDataModel();
>   static checksumModel =3D new BossChecksumModel();
>   static editorFrame =3D new HexDumpEditorFrame();
> }
>
> where they didn't even have to define any methods, yet they'd still be
> able to receive a patch dump from a device, have JSL realize that this
> is the driver for it, and for the user to be able to view a hex-dump of
> the decoded data.
>
> Now, I grant that this is a little over-simplified, but I'm trying to
> make it easy for a new synthdriver author to get *some* success. The
> first few times I tried to make a synthdriver several years ago, I
> couldn't get it to do *anything*, and I eventually went away in
> disappointment. It wasn't until later, after I had examined the Device,
> Driver, and BankDriver superclasses more closely, did I finally have
> some success. And I don't think that this should be necessary.

I agree that making a driver is too complicated.  The XML driver gets
rid of some complexities like modifying the synthdrivers.properties
file, recompiling, and tries to make building editors simpler using
EditorBuilder.

> Another thing I was trying to fix:
>
> 4 - I also feel that it would be helpful to be able to name each
> parameter with a textual name. If we did this, then we'd be able to do
> things with JSL like "Increase the parameter called 'ReverbRegeneration'
> by 10% on the selected patches".

As you can see in the above example, the XML driver supports this.
Drivers include a list of of their parameters, which includes names,
data types, location information used by the decoders, etc.  These
parameters can then be accessed by name.  EditorBuilder uses this
information to allow drag and drop creation of Editor interfaces.