Re: [Jsynthlib-devel] Changes to the GenericDevice

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

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.

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.

3 - Same goes for 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 = 0x41; // Roland
  static int modelID = 0x001B; // GT-3
  static dataModel = new BossDataModel();
  static checksumModel = new BossChecksumModel();
  static editorFrame = 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.

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".

- Joe