Keeping My Scripts Tidy

Tips and Tricks
1

Here are a few thoughts about organising scripts.

For my own sanity I look after my scripts each within their own folder under the GP Content folder. On windows this looks something like C:\Users\<username>\Documents\Gig Performer\Scripts\<myfolder>\. This allows me to add version control, reduce the risk of overwriting a script with the same name and keeping any assets associated to the script (documents, screenshots etc.) all together. Also, bug fixes or feature adds to the scripts are easily picked up.

The next thing I do when using/reusing a script, I do not load it into the script editor, for scrptlets I just include it.

scriplet

Include "<myfolder>/<myscript.gpscript>"

This will pull the script into GP at compile time. In the scriptlet, in the wiring view, this may be the only line of code needed when reusing scripts.

The same can be used when loading functional elements into a larger script such as rackspace or global script editors. It is much easier when using scriplets as they generally have a single functional requirement.

largescript

Include "<myfolder1>/<myscript1.gpscript>"
Include "<myfolder2>/<myscript2.gpscript>"
Include "<myfolder3>/<myscript3.gpscript>"

Care should be taken when loading functional fragments in this way, in that, a variable declared outside of the functions are “global scope”. So if a variable called myVar declared in more than one place will cause problems. Fortunately there is a simple rule to get round this problem, in each script always declare these “global scoped” variables starting with the name (or initials) of the containing script. The same rule applies for function names.

myscript1

const ms1_VERSION : String = "V1.0.0" // Good name
var myVar : Integer = 0 // This will cause problems if in other included files

Function myFunc()
    // Function name may be an issue if a function with the same name is loaded
End

myscript2

const VERSION : String = "V1.0.0" // This is highly likely to be reused
var myVar : Integer = 0 // This variable has already been declared in myscript1

Function ms2_myFunc()
    // Good name
End

myscript3

const ms3_VERSION : String = "V1.0.0" // Good name
var ms3_myVar :  Integer = 0 // Good name

Function myFunc()
    // Function has already been defined in myscript1
End

On <callbacks> should be used with care as it is easy to include multiple callbacks with the same name. If possible always use the Matching extension or be clear on functional splitting.

4 Likes
2

That’s also what I do for Scriptlets used in many Rackspaces. So, I can update them easily in all Rackspaces by changing the code only once.

And it is also interesting because you can easily use an external code editor when doing so.

1 Like
3

One of the items on my (longgggg) list of todos for GPScript is to add a concept of “static” locally defined variables, similar to what you can do in C.
These variables are syntactically locally scoped (you can’t access them outside the function) but they remember their values between calls.

They don’t solve everything but can be very useful.

1 Like
4

If will certainly reduce some of the file scoped variables.

5

There are a couple things that make reusing GPScript code across rackspaces easier, don’t know if it’s possible to implement them or how difficult that is.

One is ability to combine responses to events. Say I have a shared On SystemEvent GigLoaded that should be common for all racks/gigs, and then there may be specific ones in particular rackspaces. Now if I have processing for the same event twice, GPScript throws an error, it would be nice to just combine them. Same goes for all callbacks really.

Another one is failing non disruptively when a callback is waiting for an event from an entity that’s not delcared in the script explicitly. I may have a certain block or a widget or a MIDI input in one rackspace but not the other. So if I include shared code that is waiting for events from those entities, it will fail unless I add them, and in some racks/gigs they aren’t needed.

So as a consequence I have a dozen script pieces that I need to include in various parts of scripts instead of a couple.

6

I certainly make use of include scripts, makes it so much easier to share and change a script which is needed in multiple places.

Can highly recommend using VS Code as an external editor - especially with the great work done by elucid to create a syntax highlighting extension.