jsynthlib-devel

[Jsynthlib-devel] Changes to the GenericDevice

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

I made a couple of changes to GenericDevice that I just checked in. 
They're mostly of use to JSL developers, so we'll probably want a way to 
turn them on or off.

One change is that, if you select "Edit" for a patch that isn't 
recognized by any driver (and, hence, is given to GenericDevice), then 
it brings up a hex dump of the patch. You'll sometimes have to wait a 
little bit for large patches, though. I'll add a progress bar soon.

Another thing is that you can now use Generic in the "Get Patch" dialog 
to send a sysex identity request. The response from the synth (if any) 
will be put in the library and, if you try to Edit it, you'll see the 
ManufacturerID, DeviceID, etc.

- Joe

Re: [Jsynthlib-devel] Changes to the GenericDevice

[Daniel A. <dan...@us...>]

For some reasons your changes give me compilation errors. Is it possible
that you forgot to check in some of your changes? The following files do no=
t
seem to be of a proper version in the CVS:

core.LookupManufacturer, core.Utility and synthdrivers.AlesisSR16 (which
seems to be missing altogether in the repository)

Cheers,
Daniel


2006/2/4, Joe Emenaker <jo...@em...>:
>
> I made a couple of changes to GenericDevice that I just checked in.
> They're mostly of use to JSL developers, so we'll probably want a way to
> turn them on or off.
>
> One change is that, if you select "Edit" for a patch that isn't
> recognized by any driver (and, hence, is given to GenericDevice), then
> it brings up a hex dump of the patch. You'll sometimes have to wait a
> little bit for large patches, though. I'll add a progress bar soon.
>
> Another thing is that you can now use Generic in the "Get Patch" dialog
> to send a sysex identity request. The response from the synth (if any)
> will be put in the library and, if you try to Edit it, you'll see the
> ManufacturerID, DeviceID, etc.
>
> - Joe
>
>
>

Re: [Jsynthlib-devel] Changes to the GenericDevice

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

Daniel Appelt wrote:

> For some reasons your changes give me compilation errors.

Um... yeah. I noticed that. Part of the reason for this is because, when
I made he changes to the GenericDevice, I was also planning on changing
the way patches are decoded from their sysex messages. As it is now,
every subclass of Driver or BankDriver has to manuall remove the 0xF0
and the manufacturer and device ID's from the sysex messages. My plan
was that we could have a variety of "DataModels" that would know how
various manufacturers encode their sysex data... and those data models
would handle all of the stripping of the 0xF0, 0xF7, and any
manufacturer/device ID's as well as decoding the data back into 8-bit
data if need be.

When I presented the idea to this list, it caused a fair amount of
debate, and some devels didn't think it was a good idea, so I didn't
pursue it further. However, it turns out that the changes I made to
GenericDevice rely on these DataModels that I was working on. So, now,
I'm debating whether to just push forward with some next-generation
Device class (which would CO-EXIST with the current one, not replace
it), or whether to alter my changes to GenericDevice to use the old way.

I'll upload a working fix in a couple of days. So, don't panic... yet.

- Joe

Re: [Jsynthlib-devel] Changes to the GenericDevice

[Daniel A. <dan...@us...>]

Ah, okay. I think I found the relevant thread in the archive - "Limitations
in ParamModel". Until now I only wrote a very simple "editor" for DSI
Evolver waveshape patches which merely consist of only one parameter - a
sampled sinlge-cycle waveform.  This editor extends=20
core.PatchEditorFramefor which the patch has to be passed in it's
constructor so that
stripping/converting of data is handled from there and not in the driver in
my case.

Your data models seem to model a patch as a whole in their parameterised
form which allows something more in the sense of the model-view-controller
pattern. Advantages could be less conversions from and to 7 bit sysex forma=
t
and an easier implementation of multiple views for a patch - although this
is not supported yet through the JSL user interface... Sounds rather useful
I would say.
To me this seems to be more of a specialisation of a patch then of a device
or driver. But then the coupling between the driver and patch implementatio=
n
in the core package is pretty tight... presumably to minimize the number of
classes which have to be written to support a new machine...

Cheers,
Daniel


2006/2/6, Joe Emenaker <jo...@em...>:
>
> Daniel Appelt wrote:
>
> > For some reasons your changes give me compilation errors.
>
> Um... yeah. I noticed that. Part of the reason for this is because, when
> I made he changes to the GenericDevice, I was also planning on changing
> the way patches are decoded from their sysex messages. As it is now,
> every subclass of Driver or BankDriver has to manuall remove the 0xF0
> and the manufacturer and device ID's from the sysex messages. My plan
> was that we could have a variety of "DataModels" that would know how
> various manufacturers encode their sysex data... and those data models
> would handle all of the stripping of the 0xF0, 0xF7, and any
> manufacturer/device ID's as well as decoding the data back into 8-bit
> data if need be.
>
> When I presented the idea to this list, it caused a fair amount of
> debate, and some devels didn't think it was a good idea, so I didn't
> pursue it further. However, it turns out that the changes I made to
> GenericDevice rely on these DataModels that I was working on. So, now,
> I'm debating whether to just push forward with some next-generation
> Device class (which would CO-EXIST with the current one, not replace
> it), or whether to alter my changes to GenericDevice to use the old way.
>
> I'll upload a working fix in a couple of days. So, don't panic... yet.
>
> - Joe
>
>
>

Re: [Jsynthlib-devel] Changes to the GenericDevice

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

On 2/5/06, Joe Emenaker <jo...@em...> wrote:
> Daniel Appelt wrote:
>
> > For some reasons your changes give me compilation errors.
>
> Um... yeah. I noticed that. Part of the reason for this is because, when
> I made he changes to the GenericDevice, I was also planning on changing
> the way patches are decoded from their sysex messages. As it is now,
> every subclass of Driver or BankDriver has to manuall remove the 0xF0
> and the manufacturer and device ID's from the sysex messages. My plan
> was that we could have a variety of "DataModels" that would know how
> various manufacturers encode their sysex data... and those data models
> would handle all of the stripping of the 0xF0, 0xF7, and any
> manufacturer/device ID's as well as decoding the data back into 8-bit
> data if need be.
>
> When I presented the idea to this list, it caused a fair amount of
> debate, and some devels didn't think it was a good idea, so I didn't
> pursue it further. However, it turns out that the changes I made to
> GenericDevice rely on these DataModels that I was working on. So, now,
> I'm debating whether to just push forward with some next-generation
> Device class (which would CO-EXIST with the current one, not replace
> it), or whether to alter my changes to GenericDevice to use the old way.

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.

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

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.