Re: [Jsynthlib-devel] The addWidget(...) design

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

Bill Zwicky wrote:

> Joe Emenaker wrote:
>
>> ... addWidget could discover what kind of parameter a ParamModel is 
>> and automatically give it the correct widget (ie, BooleanParamModel 
>> gets a CheckBoxWidget, NumericParamModel might get a spinner, 
>> EnumParamModel would get a ComboBoxWidget, etc).
>
> Wow, that would be *really* cool.  I'd love to just whip up a sysex 
> parser, and have the GUI automatically appear.

My hope is that we can reduce the work involved in writing a driver (for 
synths that don't do crazy stuff in their sysex) so that 90% of the work 
is just defining the params (ie, location, data type, and name). Of 
course, there will always be synths that require things to be done the 
old way.

> Making that work for envelopes would be ugly though, expecially since 
> the CZ has a weird envelope.

Not necessarily. Granted, the CZ might have a wierd envelope and you 
might have to create that widget the old way (which you'd always be able 
to do). However, if it was a normal 4-point ADSR envelope, then you 
could just instantiate some EnvelopeParamModel and define where in the 
patch data the four points were stored. The Widget should be able to 
figure out the rest.

> What about when JSL provides multiple widgets for the same data type?  
> i.e. We have both slider and dial widgets for entering numeric values.

There'd definitely still be a way for the programmer to create the 
widget himself and pass it to addWidget if he didn't like the defaults. 
But, if you didn't really care, then you could leave it up to JSL to 
decide what the default boolean widget is, etc. One benefit here is that 
it would allow JSL to let the user change the default widgets. Think of 
Swing's pluggable look-and-feel. JSL could do the same thing, and let 
the user pick between "normal" widgets, or maybe some fancy ones (like a 
boolean widget that looks like an LED light that lights up and turns 
off). Or the user could decide that they wanted knobs instead of sliders 
for numerical params. If they did, then any widgets in drivers which 
were just using the *defaults* would get changed. Drivers which we 
defining their widgets explicitly would be anaffected. Furthermore, I 
don't see any reason why individual editors couldn't choose what 
defaults they wanted so that they didn't have to worry about the user 
changing them, yet could still benefit from the shorthand addWidget() 
method. Of course, there are some serious widget *layout* issues to be 
confronted. Turning all sliders into knobs could really stir up the 
layout of an editor. So, perhaps we'd need to restrict how much freedom 
there was there.... but I think that, overall, something like this would 
be a benefit.

> By the way, are you trying any of this stuff?  (You're writing a 
> driver, right?)  Most of what you propose can actually be inserted 
> into your own class tree, where you can see how well it works.

I've done some of it already. I'm actually at a cross-roads in the 
development of the driver because of the fact that my it (sorry if I 
keep bringing this up) has to convert 7-bit bytes to 8-bit ones and I 
don't want to have each param-model do this individually (which is why 
I'm campaigning for some kind of DataModel or some class to separate 
param-models from the actual Patch object). I want to start moving again 
with development of my driver, which is why I presented my whole idea 
for (what I feel is) an improvement to the param-model/widget system.

If it's well-received, then I can go make some small changes in the 
widgets and param-models and then move on with my driver. If it's *not* 
well-received, then I'm going to have to sub-class every widget and 
param-model that I want to use so that it works with my data-model 
design that I'm using for my driver.

- Joe