Update on scripting

OK - I’ll have a crack at creating rackspaces per “sound” and see how it goes. Maybe the main issue I have is the “you have to push something”. Pushing a widget knob or button is easier on a Surface Pro 3 than selecting different rackspaces / variations - but I’ve already raised an feature request against that.

Ah - I see… You are not using any kind of hardware to switch your rackspaces. What kind of MIDI controller are you using?

Yeah, I had exactly the same reaction ---- the normal “use case” would be that you send a Program Change message or an UP/Down message from your MIDI controller or a pedal or something. Clicking on buttons/knobs and even selecting different rackspaces from a mouse is intended for designing/editing your configuration. When you’re on stage, the vision was that anything you would want to adjust in real time during a performance would be done by using knobs, buttons or sliders on your controllers and MIDI expression pedals and so forth.

I didn’t know you were using a Surface. When we first released Gig Performer, we hadn’t considered the use case where one would directly manipulate things by touch on the actual device. and it was quite a surprise to us when someone reviewed GP on a Surface and discovered it actually worked quite well. We added OSC support so that one could actually use something like an iPad on stage to change GP settings over OSC.

At some point, we’ll probably take a look to see what we could do to enhance a direct touch experience on the surface but right now, as far as this particular beta is concerned, we want to focus on reliability in its intended design.

So while we did add the ability to change presets from Gig Performer, that mechanism was not intended to be a replacement for actually using rackspaces to manage sounds and really more of a way to make it easier to “initialize” a sound from an existing preset in a new rackspace.


main issue I have is the “you have to push something”.

Perfect…


var wVB3Knob : Widget
var wVB3Name : Widget
var pVB3 : PluginBlock

On WidgetValueChange (newValue : double) from wVB3Knob
    var i : integer
    
    // newValue represents a value between 0.0 and 1.0
    i = Floor(30.0*newValue)
    
    SelectPreset(pVB3, i)
    SetWidgetLabel(wVB3Name, GetPresetName(pVB3, i))
End

1.) David, could you post an example for using ADSRs? In my case I want to create buttons that start fading in or fading out some instruments (by adjusting their volumes / widget values). Is it the right way to use ADSRs?

2.) One idea for the script editor: Maybe a link/button to the introduction and SystemFunctionList (which by the way is currently broken in terms of some line indentings)?

How do we set the result of a function? And how do we leave a function somewhere in the middle?

Function Test () Returns String

End

SetWidgetValue(Widget1, Test())

Can’t find something like a return function.

(I really have to find time to get the Script language manual written)

"How do we set the result of a function"?

When you create a function that has a return type, an implicit variable called ‘result’ is declared with the same type. Whatever you assign to that variable will be the result of the function.

"And how do we leave a function somewhere in the middle"

You can’t — there’s a reason Niklaus Wirth (all hail the great language designer!!!) didn’t include a ‘return’ statement in Pascal. A ‘return’ is just a ‘goto’ in disguise and the same reasons why ‘goto’ is a terrible idea apply to ‘return’.

Ha! I tried that because I thought about Pascal, but I wrote “Result” instead of “result”. Works now, thanks.

You can’t — there’s a reason Niklaus Wirth (all hail the great language designer!!!) didn’t include a ‘return’ statement in Pascal. A ‘return’ is just a ‘goto’ in disguise and the same reasons why ‘goto’ is a terrible idea apply to ‘return’.
Okay, that makes sense. That means even lots of nested if conditions are always better than using 'return'?

One more question: I thought that you already implemented a ternary operator in GPScript… am I wrong?

Notify("AutoSustain is " + (AutoSustainIsEnabled() ? "enabled" : "disabled"))

So is it better to use something like…?

var enabledString : String ... if AutoSustainIsEnabled() then enabledString = "enabled" else enabledString = "disabled" End Notify("AutoSustain is " + enabledString)

You can write

enabledString = if AutoSustainIsEnabled() then "enabled" else "disabled" end

or even just

Notify("AutoSustain is " + if AutoSustainIsEnabled() then "enabled" else "disabled" end)

Yep, ternary operator, Algol style :slight_smile: