I have a gigfile with 20 rackspaces containing 20 plugins of the same drum kit. If I load the same drum kit in the global rackspace and then delete the other instances in the 20 rackspaces, can I then (somehow) change drum patterns, volumes, tempos etc in each rackspace?
I’m thinking that I have four basic instruments that appear in nearly every rackspace, and that if I could load say a drum kit, bass guitar, piano and organ into the GRS and still have the ability to make changes per rs, I would likely save ram and loading time. Is this idea feasible, or am I just naively dreaming?
You can do this, as long as you can change presets with a widget, then map those widgets to the local RS/variations. It is not advised, due to possible lag time in changing presets, but of course this is plugin dependent. I do this successfully with about nearly 20 plugins in my global RS. I have never encountered any issues and it’s instant for me.
If your plugins do not support preset changes via midi, you can still do it with GP 's presets/favorites.
Another way to do this that is perhaps closer to your original line of thinking and does not require plug-in preset changes is to put the kit in your global rack, setup global widgets for anything that needs to change with each local rack, and then you can link local rack widgets to control those global widgets and save settings with each local rack.
One other thought as long as your tempo is just a fixed tempo that is set with each rack, you can save tempo in the settings of each rack or variation and then just have the plugin use the “host” tempo rather than changing the tempo directly in the plugin. Just about all plugins support this approach and it is much easier.
BrianD’s answer here is correct and the one thing you need to know is when you change from rackspace to rackspace, the local widgets will change the global widgets instantly so there is no overlap of sound but for drums this is likely less of an issue than say if you were usung this method to switch a global-centric synth and you wanted seamless changes.
The other method of using variations is also valid and doesn’t require you use setlists. It just means that if you change rackspaces for other reasons you need to duplicate your drum library instance.
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).
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.
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.
so I’ve elevated your membership. You should be able to edit now.