Some new syntax coming

I’ve just finished implementing some new syntax that will simplify some code. These will be in the next update but I figured I’d mention it now in case anyone is interested

  1. In operator

You can now write

var note : integer

if note In [C2 .. C4] then ....

I.e if some received note is within the range of MIDI notes C2 to C4 then do something

(By the way, another as yet undocumented feature is that integer values can be written in MIDI notation. So you can refer to C3, C#4, Ab2 and so forth and those constants will be seen as integers where C3 is 60 and the others are whatever they are, I’m not going to calculate them right now :slight_smile:

  1. If then elsif …
    You can now have multiple else clauses in a single IF statement and you only need a single End at the end of the entire statement

  2. Select
    This is an even cleaner version of (2) above and in fact if I had done this one first I might not have even bothered implementing the elsif clause for IF statements. The Select is a bit like the C switch statement or Pascal Case statement but a little less restricted. So you can write things like

select
   a > b do
      statements

   n in [C3..C4] do
      statements

   "abc" < "def" do
      statements

   true do
      statements
end

It’s more general than the C and Pascal versions because you aren’t restricted to constants in each case. Note that there is no “break” needed. The first expression that evaluates to true has its statements executed and then you exit the select. In the example above, the last test is essentially the same as ‘default’ in C-style languages.

Hi David,

is there a way to combine two (or more) conditions in an IF statement?
Something like

IF x>0 AND y=1 then…

this would be quite helpful.

That has always worked. However, the keywords are lowercase (except for first letter where uppercase is allowed, although I’m mixed about that decision)

So you can write

If x > 0 And y == 1
   Then ....
End

And, Or and Not are all supported and the precedence is such that you should rarely need parenthesis

Thank you. This worked well. :slight_smile:

BTW: Will there be there be some basic string-handling functions implemented?
Such like RIGHT, LEFT, MID, VAL… i think they may be quite handy from time to time.

Or something i know from VBA: FOR EACH abc IN xyz … NEXT
This may be used to run through all Members of a group.
i.e. in Excel to go for each cell within a range - but it also works with objects like textboxes, buttons,…

In combination with the string functions, i imagine for GP something like:
Go through all existing widgets of a rackspace, then do some code for i.e a special class of widgets or all widgets with a special leading string in their name. Then you could make “groups” when naming them like “grp1_btn1”, “grp1_btn2”… “grp2_lbl1” and so on.

Another idea for the string functions would be to use the caption of a button to determine a special value which would be sent to somewhere (another widget, a plugin,…). For example you make a button with the caption “100”. In the script you read this caption, convert it to double and then send this value to… let’s say a parameter for resonance, or the speed of a rotary effect, or th rate of distortion, …

I can certainly add some string handling functions although they’ll look like VBA over my dead body! VBA is not intended for real-time programming.

The reason I’ve avoided string handling stuff (other than there’s a built-in concatenation operator) is because string handling is relatively expensive and the last thing one wants to be doing is messing with strings when responding to MIDI callbacks, for example.

Proper use cases are really important to drive features in a programming languages. So the notion of making a caption semantically important (which is what you’re suggesting here) makes me very nervous.

Why, for example, would you want to extract a number from a caption to use as a parameter for something else? That just sounds like the wrong way to accomplish your goal? Why would you want to group widgets based on their name (or name prefix)?

Note: I’m not saying that what you’re trying to accomplish is wrong. I’m just suspecting that the APPROACH you want to use might be wrong.

Ok… i am not the expert in developping programming languages, so the things above just were thoughts that came to my mind.
Wether they really make sense in this time-critical environment or not, is something of your competence.
I only program in VBA regularly, so this is more or less my only base to see programming-related things. Not so popular - i know. :slight_smile:
Have you seen my script with the radio-buttons in the “General Discussions” forum?
What mainly brought me to those thoughts is this idea of a group of buttons that send specific values to other widgets or plugins.
The way i see (and how i would solve) problems is based on my knowledge in VBA…
To convert the caption of a widget to a value is at first glance just a simple and flexible way to give a button some specified value which could be sent to i.e. a plugin. By using the caption one had not to dig through the script to change a value if needed, one could just change the caption and the sent value would be appropriate.
In fact i really miss a button widget which has the ability to carry a specific value (not only 1 or 0) and which is not a switch but just a button (press=1 release=0, just like the ones on a hardware controller).

OK — we definitely need to do a button widget but it is possible to emulate that with a script. I created a red LED button and called it MyButton. Then use the following script

//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
   MyButton : Widget
//$</AutoDeclare>

// Called when a widget value has changed
On WidgetValueChanged(newValue : double) from MyButton
    OpenLogWindow()
    if newValue > 0
       then
          Print("Pushed")
          SetWidgetValue(MyButton, 0)
    end    
End

Note that you could always use other knob widgets to define values and you can then ask your button for the value of another knob. That’s why I was skeptical of the notion of grabbing the value from a caption.

But a knob as it is now has only two conditions (besides its switch bevaiour): 0 or 1
What if i wanted to press this button to set a parameter to 0.71234?
A button cannot have such a Value, or can it?
Sure i could write a code to set the desired parameter to that value, but then the value comes from somewhere out of the script and not from the button itself. My idea is to have button that has (naturally) its two conditions 0 or 1 but also another value that is sent to the destination when it’s pressed. Let’s say i press such a button, then it’s own value is 1 but it also sends the “send-value” (maybe 0.71245) to… i.e. the resonance parameter of a plugin.
I still think this would not be the worst thing to have. :slight_smile:
(But in case i am the only one with such a wish, i won’t be nagging you anymore with this :wink: )

Knobs (dials) and sliders can have any value between 0.0 and 1.0 (exposed in the Gig Performer Knob properties as percentages so between 0.0 and 100.0)

Buttons are generally 0.0 or 1.0 but if they’re associated with some parameter you can use parameter range and control to set a min and max value for them

Doing what you want is trivial with GPScript - see below

var 
   SomePluginBlock : PluginBlock  // One of your synths or effects plugins, say
   MyButton : Widget  // This is a push button
   MyKnob   : Widget  // Some knob that can be turned to any value between 0.0 and 1.0

On WidgetValueChanged(newValue : double) from MyButton
    OpenLogWindow()
    if newValue > 0
       then
          Print("Pushed")
          SetWidgetValue(MyButton, 0) // This just resets the LED so that it looks unpushed again

          // Now set parameter 42    of your plugin block to the current value of MyKnob
          SetParameter(SomePlugInBlock, 42, GetWidgetValue(MyKnob)) 

    end    
End

I know, David. I know.
But a button with a (let’s call it) “send value” field wouldn’t need scripting at all, nor would it need additional knobs or sliders.
Just fill in a value and “fire” it to the desired destination.

But yeah… if i ever need it, i will do it with a script. No problem.
Thank you for your patience.

The next beta update will include some string manipulation functions such as finding a substring, replacing a substring, trimming the string and so forth. We can see what else is needed but i want to be really careful here as string manipulation is not something to be encouraged, there are probably better ways to accomplish goals

@David: Have you kicked out the “select” function?
Or was it never included?
I tried to use it, but it won’t work.
Any suggestions?

Select works just fine.
For example,


initialization
   select 
      1 < 3 do
           Print("A") 
      3 > 4 do 
           Print("B")
   end
   
end

Thank you.
Ok… i will give it a try. Tomorrow.

I use the same script on all my rackspaces. Then when I think of something new to try, I have to copy and paste 20 times. Would really help if there could be a universal script that applies to all rackspaces. I’m using gpscript to control other software and hardware.

Unfortunately, it’s not obvious how to do that — rackspaces are generally unique so something that applies to one generally doesn’t apply to another. So what happens (say) if you have a universal script that refers to “Knob1” — to which rackspace does that apply, and what happens if a particular rackspace doesn’t have a “Knob1”?

It might make sense to have the ability to define some functions that are then available to all your scripts. But you then run the risk of breaking individual rackspace scripts…for example if you define a function in a shared script that expects to find “Knob1” and some of your rackspaces don’t have that “Knob1”, the scripts for those rackspaces won’t compile and those rackspaces won’t function properly.

So that means that any time you make (what you hope is) a trivial change, you have to carefully test all your other rackspaces. That makes me very nervous. Imagine you decide to make such a change right before a show, just because you need to tweak something. You think it’s safe but then you get on stage and 12 rackspaces stop working properly.

That’s really why I haven’t implemented that concept yet.

I’m totally open to thoughts on how to approach this but safety and low risk are very high bars here.

That lead to an idea.
In mainstage there is a oncept of alias channels.

What about the idea of alias panels, which could be defined once and referenced in individual rackspaces.
And script can be defined on alias panels.

In my case i am using always 2 widgets to be used by my hardware controller.

I have similar issues - lots of rackspaces that are mostly the same. As a guitarist (mainly) I have very similar rigs in my rackspaces but there will be something different (like an amp sim or an effect). David’s point is a very good one - I don’t want to accidentally reference something that doesn’t exist. But I do often want to update some code that then has to be duplicated multiple times through the gigfile.

The idea of ‘alias panels’ would work nicely for this. I guess the ‘alias script’ would have to be ‘included’ into the script for the rackspace.