Keeping My Scripts Tidy

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 scriptlets I just include it.

scriptlet

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 scriptlets 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.

7 Likes

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

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

If will certainly reduce some of the file scoped variables.

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.

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.

Here is a little trick I discovered recently that allows selected settings in a scriptlet plugin block to survive recompilations.

example:

By putting fixed (CONST_) definitions ahead of the included code, you can write the included code to set variables or even parameters according to those definitions.

IOW, for example, the included code may set the PC_Channel parameter to 1 by default,

PC_Channel("Channel"): Subrange Parameter 1 .. 16 = 1

but for the plugin block shown above, PC_Channel will always be set to 2, like so:

Initialization
PC_Chan = CONST_PC_Channel
PC_Upper_Bound = CONST_PC_Upper_Bound
End

as intended for the specific plugin block as deployed with specific wiring in a specific rackspace.

I want to clean up my scripts this way. My script files are in a google drive so I can share it between computers. How can I get the path set correctly for this?

On my PC it would see it as this: G:\My Drive\Gig Performer\scripts\MyScripts\Global

I would use symbolic links to associate your Google Drive with the Scripts folder that’s under the Gig Performer folder in your Documents directory

1 Like

When you donut this way it’s ok that the variable declarations aren’t all in the same place at the beginning of the script since the script is calling multiple script files?

Yes, but variables must be declared before use.

That has nothing to do with symbolic links - even if you kept everything in your GoogleDrive you would still have to deal with this.

Scripts are not “modules”, so there’s no implicit scoping for global variables - consequently global variables are global across all scripts that you might include.

So I would recommend that you name your global variables with a prefix, perhaps the script name.

Also @Spav is correct that variables must be declared before use so you need to think about how to organize everything.

I didn’t mean the symbolic links thing I meant including multiple scripts. It seemed like there might be a danger of variables being declared in the wrong place but I just put three scripts together and it worked out well.

Let me try and get this so I have it straight, the link i would put in options/locations/content should be a symbolic link that points to my google drive folder where I have the scripts stored?

I followed the instructions to create a symbolic link for the scripts, and pointed to the symbolic link (which is in a google drive folder) but on loading, gig performer keeps adding “library” inside the file path where none exists and so cannot access my scripts. Is there a foolproof way for making symbolic links in google drive in a way that Gig Performer will see it correctly?

This is on my windows machine setup with dropbox.

The locations in the GP options is default. The script folder is in the GP default location, the symlink is in Drobbox folder. Finally the include in the scripts is relative.

1 Like

This looks like what I’m trying to do, I’m not sure the proper steps to make sure the symbolic link I created appears that way