"GP User Presets" file location

Scripting with Gig Performer
1

The gig file I’m working on these days is called “rockband”. I want to create reusable scriptlets to be used in any of the rackspaces in my “rockband” gig; is it necessary to save them as separate files or can they live inside my gig file? (They’ll be meaningless outside of the “rockband” gig because they’ll be relying on code that’s in my global rackspace script, so I don’t want them to be available in other gigs.)

Since it seems that the only option is to save them as separate files, I poked around and noticed that in the standard Presets folder there is a “Deskew Technologies LLC” subfolder with some nice little scriptlets in it, so by analogy, I created a “Rockband gig” folder alongside it. When I went to save a scriptlet there, I got an error message:

ERROR: Non Standard Location

Presets stored outside their default folder location will not appear in favorites or preset menus.

Saved location: C:\Users\Solomon\Documents\Gig Performer\Presets\Rockband gig
Expected location: C:\Users\Solomon\Documents\Gig Performer\Presets\Deskew Technologies LLC\Scriptlet

However, it seems to have saved successfully in spite of the error, and now when I right-click in my wiring view to add a plugin, alonglide the “Deskew Technologies LLC” submenu I see a “Rockband gig” submenu with my saved scriptlet in it. This is exactly the behaviour I was hoping for, because I don’t want my “rockband” scriptlets to be mixed in with any other non-“rockband” scriptlets, and I don’t understand why it’s an error.

Is it the case that I’m expected to save all my scriptlets from every gig under “Deskew Technologies LLC\Scriptlet”, where they’ll be a distraction when I’m working on other non-rockband gigs? What problems will I be causing for myself if I create more folders for better scriptlet organisation?

2

Oops, apparently Presets aren’t actually what I want at all. (I looked in those saved files, including the one I created, and they contain XML and don’t appear to actually contain any GPScript source code.)

So my actual question is this: how do I make a scriptlet available as a plugin in all of my rackspaces without literally having copy and paste it? When I update the scriptlet source code I want every rackspace that uses it to get the updated script, rather than having to go through and manually replace the scriptlet in every rackspace.

3

I don’t think anything works that way in GP. There’s no ‘master’ file to update that way. Each scriptlet, once loaded into a rackspace, becomes its own entity and is entirely separate from every other instance of that scriptlet in all other rackspaces and gig files.

4

Hmm. Okay, well then I’m probably not approaching this problem correctly.

In my global rackspace I have eight instruments (the ones I’ll most commonly be needing), and in the local rackspace I’ll also have between zero and eight additional instruments (for a total of up to 16). I’ve written a lot of code in the Global Rackspace Script which implements a fairly complicated user interface (including a 16-instrument mixer plus panels to control each of the 8 global instruments, plus vocal microphone processing, main outputs, IEM outputs, a metronome, and so forth), along with implementing keyboard zones, handling sustain and expression events, knob and slider events, note events, etc. MIDI data which are destined for any of the 8 global instruments are given MIDI channels 1-8 and routed accordingly, and MIDI data which are meant for any of the local rackspace instruments are given MIDI channels 9-16 and sent to the local rackspace to be handled appropriately.

I’m trying to figure out the best way to control the parameters of the global rackspace from the local rackspace, so that each local rackspace can have different Hammond drawbar settings, amp/cab and effects settings, mixer levels, and so forth. (The organ VST, the effects, and the mixer are examples of things that live in the global rackspace.) I would of course like to use widgets in the local rackspace to control these settings rather than burying them in the local rackspace script where I can’t easily see and modify them. Global parameters are not the answer because I expect I’ll need more than 128 parameters. (Any particular rackspace probably won’t need that many, but overall there will probably be more than 128 possible settings to tweak.)

I have yet to play with scriptlets at all, but I was thinking that the way to go would be to have 8 reusable scriptlets (one for each global-rackspace instrument), plus additional reusable scriptlets that control other global rackspace settings (such as the names of the local-rackspace instruments to be displayed on the global rackspace mixer panel, master effects, and other stuff.) Each of these scriptlets will have its particular parameters that can be controlled by local-rackspace widgets, and changing those parameters will trigger the scriptlet to send OSC messages to the global rackspace which will then twiddle the corresponding global-rackspace widgets which will be linked to the parameters of the global-rackspace VST’s.)

So, I’d have a “Hammond” scriptlet, a “vibraphone” scriptlet, a “global reverb” scriptlet, an “instrument names” scriptlet, and so forth, which I’ll use in the local rackspace the same way I’d use VST plugins.

The problem is, I want to make these scriptlets reusable. I don’t want each rackspace that wants to use the global Hammond plugin to have its own separate copy of the “Hammond” scriptlet, because I’m sure that I’ll be often modifying and improving that scriptlet in the future.

What’s a better approach?

5

The only possibility I am aware of is for the scriptlets to reference a previously saved script file e.g.
Include "Hammond"

So, wherever you are managing your master scriptlet, once you make changes, save the script file from within the script editor. It defaults to a “Scripts” subfolder within your main Gig Peformer folder.
e.g. save as Hammond.gpscript

Then, any other scriptlets should just use Include "Hammond"
image

I don’t do this, so you’d have to test how well it works.
But note, if you do changes to the parameters (or order), it may break any widgets you have connected to them.

6

Why not just put just the instruments you need for each song in its own rackspace?

7

Maybe that is simpler… it’s just that some of my “instruments” have some pretty complicated logic going on. For example, my “electric piano” is a blend of Rhodes, Wurlitzer, and DX7 (the particular proportions of which will vary by song); for my “horns” I wrote some code (which I’m not yet quite happy with) to divisi the chord into separate instruments with voicings depending on range; my Hammond will have some magic with pitch bend and sustain (since the underlying VST doesn’t support those itself). But yeah, I’ll give that idea some serious consideration.

8

What’s the principle behind this? Do you use a GPScript? I would be curious to know more about how you achieved this.

9

Actually, I haven’t implemented this part yet, but I was thinking I would first try to continuously change the tuning parameter of the organ, and if that doesn’t have the desired effect then I was thinking I would try to insert a pitch-shifting VST after the organ.

1 Like
10

Aha, yes, this looks like it will do what I want. Thank you!

I haven’t tested this yet with Scriptlets, but I’m using it in the rackspace script to implement some functions for sending commands (via OSC) to my Global Rackspace script and it’s working great.