Drum kit plus other plugins in the global rackspace

I should have added that not just presets of course, anything that can be controlled with widgets, can be controlled from local RS.

Take in account that a sample based plugin, like Strike2, needs to load a new sample set each time you change a preset, which will need a moment and prevent it from being played instantly.

Great! Let us know how it goes. One additional note - not sure that article specifically addresses tempo, but there are four levels of tempo (in addition to setting global tempo directly) that you can use in GigPerformer. In order of precedence from lowest to highest - the foundation is global tempo, then you have three overrides - local rack tempo, variation tempo, and setlist song tempo. The tempo settings are built right into the definition of each of those entities and GP will change the tempo when you switch to them if it is set.

No - this does not require the use of setlist - basic local racks or variations save and recall all the settings of their widgets. Though if you were using setlists, you can associate each song or song section with a rack/variation and it will recall all the widget settings in that rack/variation when you select that song/section. You can even then go one step further and then save song/section specific adjustments to the widgets along with the song/section. Super elegant and flexible.

Oops - that last post should have said three levels of tempo in addition to global, or four levels of tempo overall. New enough member here that I don’t have the ability to edit that answer so fixing in a reply here.

For VST parameters you can map them to widgets in the global rackspace and expose them as parameters that can be mapped from widgets in the local rackspaces.

The global rackspace does not have variations.

Presets are harder. It is discouraged using widgets to perform preset changes. I’ve been burned doing this with an unstable gig and crashes.

Best way around that is multiple instances of VSTs in the global rackspace but use widget buttons and scripting to make a radio button selection of the VST that should be activated. The rest remain bypassed.

No, I meant rackspace variation. (And every rackspace has at least one variation).

As I understand it, variations use the same loaded sound source. So each additional variation does not use additional ram (of any significance).

For the most part set lists just allow you to select variations. But it makes it easier to use them for a gig (I think). One exception is, if you do change a widget setting in a song part, you can freeze that setting for that song/song part without affecting the rackspace variation.

That’s how I understand it. (See disclaimer, above).

It doesn’t appear you’re a spammer :stuck_out_tongue_closed_eyes: so I’ve elevated your membership. You should be able to edit now.

1 Like

I was thinking about Strike 2 Erik, and the fact that you introduced me to it. Strike 2 is one of the plugins I use a lot. I was wondering about how to change various aspects of Strike 2 if it was placed in the GRS instead of 20 instances in 20 rackspaces. For example, each rackspce would need to control rhythm, various volumes (kick, snare etc), fills editing and so on. This would preclude using it in a global sense do you think as too many changes would be needed from rs to the next rs? On the other hand, simple plugins that don’t need any changes from rs to rs would be ideal in the GRS. Just my thoughts here.

I started using GP with version 1. When V2 arrived with the set list feature added, I had already built up a library of 150 rackspaces in sets of 20. I asked on the forum at that time about whether set lists would work for me, and the advice came back to me to just stick with rackspaces. The main reason for that advice was that each of my rackspaces is a complete song with a full rhythm section. Since then, I have added drums, pattern playing bass plugins and Kontakt instruments that are heavily into ram use (1 gig plus in certain cases). I have applied tips such as ram saving using purge, but still find that even with predictive in use, I have to wait many seconds when changing to the next rackspace before it becomes active (plugins must change from red to green). As I play live, it is a concern to me that I can’t get onto the next song more quickly (10 to 12 seconds is a long time when playing live).

I have been thinking about this for some time now trying to improve what I have and increase efficiency. With well over 400 rackspaces, I think that making changes could be a huge undertaking that may not work out any better in the long run. I would welcome any thoughts or suggestions.

Any chance of uploading a sample rs?

I’m gigging 3-4 times a week, but sure, next time I’m home with laptop I’ll put something together. Until then… The basic concept is, I have a bunch of synth plugins that respond to program change messages from scriptlets connected to each plugin. The PC messages are sent from regular rackspaces. The plugins are bypassed using the plug-in persist bypass by @David-san.

Then it is the right time for an update :wink:

3 Likes

I’ve already updated! Thank you for your script!

1 Like

Could someone upload a very simple rackspace demonstrating a VST in the GRS with a gain control in the normal rackspace. Thanks.

Ok… the active pattern within Strike2 (Intro, fills, etc…) will be played by receiving the according note message, and these will of course vary during the progress of a song.
But do you really adjust the diffrent volumes (kick, snare…) on the fly during play???
How many and which of those parameters had to be accessed then?
I thought of something like “Call a particular preset” (which will include, the drum set and the style) and then play the desired patterns by sending the according note messages.

Thinking about the Strike plugin - I’ve decided to just keep it in the local rackspace and load from there as needed. Too complicated and too many variables to change. otherwise. And then I will then just load a handful of plugins into the GRS such as harmonica, pedal steel, organ etc as a starter. I’ve asked for sample rackspace to get me started.

Deleted

Here you go - I just used the built in plugin Audio Player to demonstrate so you don’t need anything other than GP to see it work. Three variations in a Local Rack that change the volume of Lane 1 in a Global Audio Player.

Demo Local Control of Global.gig (43.4 KB)

2 Likes

Many thanks for that!
I’ve been experimenting over the weekend on two gigfiles containing 20 rackspaces each. I have transfered oft used plugins from the local to the global rackspace. The first gigfile shaved 19 seconds off the loading time, and the second reduced the loading time by 88 seconds. These are significant gains for me and I am very pleased with the results. Predictive turned off using a Surface Pro 8 with 16gig ram.

1 Like

I’m a little (a lot) late with this…sorry about that! I put my setup in this thread here.