jsynthlib-devel

[Jsynthlib-devel] Limitations in ParamModel

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

The current driver I'm working on deals with 8-bit bytes (after 
unpacking them from the 7-bit ones that MIDI uses). It *also* uses some 
values that span mulitple bytes (ie, MSB/LSB).

 From a brief look at the ParamModel class, it looks like it's not 
really going to help me here. As a result, I suspect that the *Widget 
system is, likewise, not available to me, correct?

- Joe

Re: [Jsynthlib-devel] Limitations in ParamModel

[Bill Z. <wrz...@po...>]

Joe Emenaker wrote:

> From a brief look at the ParamModel class, it looks like it's not 
> really going to help me here. As a result, I suspect that the *Widget 
> system is, likewise, not available to me, correct?
>
In-correct, Widgets will work just fine for you, but you need to make 
your own model classes.  This is really easy, there's even instructions 
on jsl.org.  I had to crank out a whole buncha custom model classes for 
my CZ; it's annoying, but easy.

-Bill

Re: [Jsynthlib-devel] Limitations in ParamModel

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> From a brief look at the ParamModel class, it looks like it's not 
>> really going to help me here. As a result, I suspect that the *Widget 
>> system is, likewise, not available to me, correct?
>
> In-correct, Widgets will work just fine for you, but you need to make 
> your own model classes.  This is really easy, there's even 
> instructions on jsl.org.  I had to crank out a whole buncha custom 
> model classes for my CZ; it's annoying, but easy.

Well, I just tried a different approach... and I'm interested in its 
potential.

I made a "DataModel" interface. The idea behind it is that it handles 
all of the nuisance of stripping off leading bytes (ie, F0, manufID, 
devID, etc) and trailing F0 and it handles any conversion to/from 8-bit 
bytes or whatnot.

Then, I made a new ParamModel which, when it needs data, asks the 
DataModel for it. So, the ParamModel and addWidget never need to see the 
actual Patch.

The beauty here (well, *I* think it's pretty neat, anyway) is that the 
DataModel would be able to handle multi-byte values. It would know 
whether to use LSB-first or MSB-first. It would also know how strings 
are stored (ASCII... 0-terminated... whatever). So the ParamModel would 
be able to just ask for multi-byte values by asking for the offset and 
the number of bytes:

   dataModel.getInt(0x245,4); // Get a 4-byte int

or....

   dataModel.setInt(0x245,4,somevalue);

- Joe

Re: [Jsynthlib-devel] Limitations in ParamModel

[Bill Z. <wrz...@po...>]

Joe Emenaker wrote:

> I made a "DataModel" interface. The idea behind it is that it handles 
> all of the nuisance of stripping off leading bytes (ie, F0, manufID, 
> devID, etc) and trailing F0 and it handles any conversion to/from 
> 8-bit bytes or whatnot.
>
> Then, I made a new ParamModel which, when it needs data, asks the 
> DataModel for it. So, the ParamModel and addWidget never need to see 
> the actual Patch.

So did I, good job.  :)

Two things to watch out for:
* In Java, bytes are signed.   So if the range is 0..255 before, casting 
it to a (Byte) will change that to -128..127.  Thus, reading 
patch.sysex[index] may yield negative numbers.  I had to compensate in 
my CZModel.getByte.
* Java ints are only 4 bytes, so you can't grab any more than that at 
once.  Ints are also signed, so if you grab 4 bytes, you'll get negative 
numbers again.  Longs are 8 bytes.

-Bill

Re: [Jsynthlib-devel] Limitations in ParamModel

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> I made a "DataModel" interface. The idea behind it is that it handles 
>> all of the nuisance of stripping off leading bytes (ie, F0, manufID, 
>> devID, etc) and trailing F0 and it handles any conversion to/from 
>> 8-bit bytes or whatnot.
>>
>> Then, I made a new ParamModel which, when it needs data, asks the 
>> DataModel for it. So, the ParamModel and addWidget never need to see 
>> the actual Patch.
>
>
> So did I, good job.  :)

I think DataModel might be the next stage in the evolution. ParamModels 
alone won't really cut it (in my case anyway) because I'm having to do a 
7-bit-to-8-bit conversion on the whole patch before I do anything with 
it. If I did this in each ParamModel, there'd be a conversion happening 
for *every* Widget in my editor which, potentially, could lead to long 
delays for the editor to load. Also, because the 7-to-8 encoding 
"intermingles" the bits of each byte with neighboring ones, it'd be very 
tricky to try to have each ParamModel try to sneak its param data into 
the undecoded patch data itself.

> Two things to watch out for:
> * In Java, bytes are signed.   So if the range is 0..255 before, 
> casting it to a (Byte) will change that to -128..127.  Thus, reading 
> patch.sysex[index] may yield negative numbers.  I had to compensate in 
> my CZModel.getByte.

Yeah... I've hit this kinda thing before. Most-recently, it was when 
doing right-shifting of bits. If you do ( 0x80 >> 1 ), you don't get  
0x40, you get 0xC0 because Java figures that the high-bit was on, and 
needs to stay that way. Uh... okay.

> * Java ints are only 4 bytes, so you can't grab any more than that at 
> once.  Ints are also signed, so if you grab 4 bytes, you'll get 
> negative numbers again.  Longs are 8 bytes.

Right! Well, here's where things can get really fun with DataModels. 
Some synths (like the Alesis I'm working on) use 8-bit bytes for the 
actual patch data, some use 7-bit. The DataModel would be aware of this. 
Part of the interaction between ParamModel and DataModel could be one 
where ParamModel declares to DataModel how many bytes it wants, and what 
the highest value it expects to be able to use with it. Then, the 
DataModel would do the calculations to make sure that it was possible.

For example, suppose DataModel has a method called isInRange(int bytes, 
long highest value)...
For a DataModel which used 7-bit bytes,
   isInRange(1,127) returns true
   isInRange(1,128) returns false
   isInRange(2 16383) returns true
   isInRange(2,16384) returns false
Meanwhile, for a DataModel which uses 8-bit bytes,
   isInRange(1,128) would return true....

Maybe this is overkill... but I like the encapsulation of it.... and I'm 
an encapsulation whore.

- Joe