I am wondering if I can create a VST based guitar ‘rack’ and VST based Synth ‘rack’ and somehow put incorporate them both inside a Rackspace? I’m not sure what this ‘rack’ would be… a separate Rackspace possibly?
The whole point is I’d create modular instruments (with a corresponding panels), that could be dumped into a Rackspace as needed. For example a song needs a guitar and specific synth, I create a song Rackspace that includes those two ‘racks’ and all I do is hook them up to IO ports and mix them. Perhaps even sending their output out to a post effects ‘rack’.
Are you familiar with “Favorites”? Although we don’t yet support panels for them, you can define a set of connected plugins and save them all as a favorite so as to insert them in one go wherever you need them.
You would still have to recreate any widgets though.
Thanks guys, I think your responses answered my question! GP doesn’t work like that.
Just talking out loud from here on…
In my mind (using the real world analogy) I think of a Rackspace as the holder of many ‘rack units’ where each rack is a defined unit of doing something… effect unit, instrument, mixer… all wired
together. In the analogy, GP has 1 Rackspace (well 2 include global) with an everything ‘rack’ in it.
The idea of using favorites or simple cut/paste does work. It just means either I’m creating one giant ‘do everything’ rack (disabling what’s not used) or custom creating racks by cut/paste per song as needed.
It’d be great if it were modularized… I think of a GP Rackspace as computer program without the use of functions (or objects). We are cut/pasting code from different sources to achieve a result. If a modular ‘rack’ existed, it would be a function (or object) that can be reused all over the place (including its panel). Changes in a ‘rack’ (function) would propagate to all that use it.
(Seem the multiple instance idea from Jeff could pseudo achieve this modularity but I’ll leave that alone for now… sounds tricky)
Anyways thanks for listening if you made it this far. Lol.
Jeff
By the way, if you use Setlist mode, you can use any rackspace variation with any song part. So, if you created a rackspaces variation for another song, but it is perfectly suited for a part in different song, you can just associate that rackspace variation with that song part.
In the GP world, a rackspace represents a collection of plugins, connected any way you like - could be multiple separate plugins or they could be connected to each other any way you like.
The whole point is to not have everything in a single rackspace – your CPU won’t be able to handle that (and it would be far too complicated to manage anyway). Since you can switch seamlessly/instantly from one rackspace to another, it’s a better way to manage a large collection of songs each of which uses different combinations of plugins. If you have a lot of songs that use the same plugins but in different ways, then you can use variations in a single rackspace.
And of course, then there’s setlist mode where you can reuse rackspaces in different ways.
So let’s say I create 3 rackspaces one for each a guitar, synth and voice… each with it’s own specialized panel to control it. I have many songs that use any combination of these.
Solo guitar piece song uses just the guitar rackspace
Acapella song uses a specialized voice rackspace.
If I have a song that uses guitar and synth, I create a new rackspace copy/paste contents of guitar and synth rackspaces. Recreate the Panels from scratch… hook them up.
Guitar, Synth, Voice song… same thing but bigger. Cut/Paste… redo the panel.
Etc…
This problem gets big fast as I add new instruments and effects down the road.
Furthermore, say I want to change something in the guitar rackspace or it’s panel… I can, but now I have to update each instance I copied and pasted it to! (or not!).
The end result is I probably just have bigger all encompassing rackspaces and switch things on/off with variations.
Disclaimer… I am new to GP. I’m the first stages of figuring out the best way to organize everything and this the problem I’m running into. My computer coding mind thinks in term of modules or functions. Create it once (black box it) and reuse it… not copy/paste.
GP has the start of this concept with global rackspaces… connecting a rack to a rack.
If you have a rackspace that has some/most of what you need, you can always add another “instruments” (plugins) to that rackspace and then you can always “bypass” them when not used. So, bypassing some instruments (using widgets) in variations, is an important option to consider.
So, in your example, you could have one rackspace that covers everything you mentioned and then use “variations” to bypass the plugins you do not use in a particular song (or song part). (But, this might get a bit unwieldy, but probably not based on what you actually listed).
I still am a bit ad hoc about how I handle this. I sort of look for rackspaces to reuse. I have to consider whether to add something else to an existing rackspace and bypass it on that variation (but unbypass when I want to use it).
I am considering whether I want to add my honkey-tonk blues harmonica sample library to the Global Rackspace because I am using is pretty often.
Note: each time you use a sample-based instrument in a different rackspace, it is loaded again into ram. So, this is a factor to consider in all this.
But, all that said, I am amazed every day what I can do using Gig Performer. Love it!
This is what I was trying to avoid. Instead of adding to existing rackspaces till they get too big and unwieldy with all the details of a new instrument, simply add a new ‘rack plugin’ and connect it. The details of that new ‘rack’ instruments wiring and panel are defined in another place. (.rack file?)
With a modular ‘rack’ object you only include those instruments you need in the rackspace for a given song. This get’s away from being forced to create ‘everything’ rackspaces.
In a modular ‘rack’ containing large sample instruments, it would be only loaded once since it’s a shared ‘rack’. Its parameter are changed per usual via variations in the encompassing rackspace.
I totally agree! Both the range of functionality and flexibility of GP is absolutely amazing. I love it too.
As mentioned before I am brand new to GP and this is my initial impression. The paradigm of ‘racks’ in a rackspace is sitting right there. Each ‘rack’ would be defined my it’s I/O and panel as a self contained unit ready to be dropped in… kind of like a VST plugin itself… except its native to GP.
Anyways this has turned into a feature request of sorts I guess… lol… and a big one at that. David, I know you are the main developer… (even the owner of GP?), just curious to know what you think.
Again, maybe I’m way off base and totally missing something here. Wouldn’t be the first time. Lol.
One downside of your suggestion is you are still stuck with using a single thread of a single core (as I understand it) on all these rackspaces.
So, I think, if the developers went in this direction, it should include a way of accessing the additional cores on new machines that have large numbers of cores.
So, I would think they are better of making it easier and easier (even for users like me) to use multiple instances. (So, it is about as easy to as using multiple instances of a plugin in a single rack).
The tradeoff, I believe, is that you can not use shared elements within a single instance of GP (like the Global Rackspace, System Actions). [I may be moving beyond my knowledge base here though, hah!].
I suppose they might have to think about how the GUI is configured when multiple instances are used (maybe they already have, I have not tried using multiple instances as of now). I suppose you would want to have ready access to the panels for the active rackspaces on each instance. So, for example, if you are using two instances, you should have ready access to the widget panel for the rackspaces used in both instances. (Just thinking out loud here).
I’ve been thinking about this a bit lately. Thinking out loud too! Lol!
I’d love to hear David’s take on this!
It seems a Rackspace in Gig Performer is logically suited toward a single Instrument. People create a tailored instrument using collections of VSTs and hardware, spice them up with scripting and a nice personal UI. These can get complicated.
What happens if I have two complicated instruments I need for the same song. How about a hybrid synth with many VSTs and a guitar using different effects and plugin across vendors. Now both have to live in the same Rackspace. What happens if I add another one? It get’s bigger and messier.
This may be where people decide to use multiple instances. This breaks things down logically into components but its not a great solution, more of a workaround. Having a some kind of intermediary component (plugin of plugins or ‘rack’) seem an logical fit to solve the problem. I’m sure the developers must have considered this at some point.
So I wasn’t sure if GP uses multiple threads internally. So running effects in parallel doesn’t reduce latency as opposed to running them in series? Interesting.
Ultimately, everything depends on where developers want to go with this.
