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