Script language questions

Now that the basic scripting system is in place, I have a couple of language questions for which I’d like some user feedback

  1. There is a notion of a type called Widget and things like knobs, sliders and buttons are all of type Widget. Question: should there be separate types for Buttons, Sliders and Knobs so that you can’t use functions that would only apply to some of these things?
    For example, you could ask if a slider is horiztonal or vertical but you can’t ask a button or knob that question. You can set a knob or slider value to any value between 0.0 and 1.0 but you can only turn a button on or off. Proving these extra types would add some extra compile time protection but do people care?

  2. Same question for blocks. There’s a basic block which you only set a parameter and have a parameter callback. However, the MIDIIn and MIDIOut blocks have extra functionality. Should we have a notion of an “AudioBlock”, “SynthBlock”, “EffectBlock” and so forth, even though those things would not be able to do anything more than a basic block can do. It’s really a question of whether people want to think about MIDI blocks vs Synth blocks or are people ok with MIDI blocks vs blocks.

For what it’s worth, my partner and I are completely divided on this topic so we’d love to get opinions from others, the more the merrier.

Think it might make more sense to have separate types for Button, Slider, and Knob, which would inherit from the Widget class [type]…perhaps the same regarding Block and its subclasses [sub·types]…thereby avoiding any functionality issues.

Else, if you stick with the one Widget type (and Block type), functionality “legality” checks would most likely have to be made for each sub·type.

Either way, I know you’ll end up with a solid solution. :slight_smile:

Best,

Mike

+1 for “more type better compiler check”… today I was experimenting with a script for manage “garritan style library” (mod wheel used to control velocity and expression) from a mix of knobs, values and direct noteOn velocity… and more check mean less error…

I agree with Michael. Everything that makes the code clearer is reasonable … and “Widget” is very general.

Same for the blocks. I like to see immediately if a variable is an AudioBlock, SynthBlock or EffectBlock.

The bigger the “pallet of colours” to start with? if this makes sense…

Actually, not really. The point of separating the types would be to restrict what you can do with each kind of widget to reduce errors. It’s not to give you more to work with. It is in fact to better constrain what you can do

I would prefer that we have Button, Knob, Slider, etc subclasses as well. As already said by some, the more restricted a class’s functionality, the fewer coding errors we will make. Extra compilation time is welcome if we get more subclass types IMO.

As for Blocks, I have less of a strong feeling on this one. I see no harm in having more subclasses but I suspect the benefit is less obvious.

tldr; Widget subclasses: definitely, Blocks subclasses: probably.

Such changes are not going to impact compile time.

GPScript is not really a class-based system, it’s more of an ADT only.

We will create Button/Slider/Knob at some point but probably not until after we release the first version of GP2

As I said earlier, GPScript will be in flux for some time as we hone in on features. As you might appreciate, language design is not a trivial activity to get right the first time.