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.
Sorry for posting to an old-ish thread. I’m a total noob with GP. Still working with the free trial. I thought you might want to know that the multiple simple rack behavior you are seeking is in Cantabile. I’m over here trying out GP because of a particular issue I was having with Cantabile. I was almost ready to let my Cantabile subscription lapse and buy GP, but this rack business is making me rethink that. Too many, too complicated. I just spent hours making a "guitar’ rack with variations, but now I see that I can’t directly re-use that work. Sigh…
Not true, with a few exceptions where I step forward and backwards over a few rackspaces during a song (via song parts in setlist mode), I typically have one rackspace per song with every instrument and effect I need in that rackspace. I’ll use variations to tweak stuff, e.g. a “solo” variation might make one sound louder and brighter.
I perform with up to four controllers and lots of splits on all of them as well as an eigenharp with which, for example, I play all the parts of Welcome to the Machine (except guitars but including bass) as well as the effects in a single rackspace on a machine from 2018 (I used to do it with a machine from 2012)
The main exception is when I have to perform a medley where each abbreviated song has completely different sounds. In that case, I’ll create an individual rackspace for each portion and just step through them via a sequence of song parts.
Obviously using the right plugins that don’t use absurd amounts of CPU is important but I typically use physical models for pretty much everything except effects where I use Kontakt.
I too bought Cantabile but migrated to GP. I originally created this thread because of Cantabile’s ability to create reusable ‘racks’ (as raydyo mentions). The idea that a GP rackspace could be defined, then dropped into another rackspace as if it were a plugin seemed a logical thing to have. It would promote the modular componentization of instruments and virtual devices in the GP ecosystem. Ultimately it would cut down on the need to cut/paste existing rackspace components to new rackspaces as well as the need to recreate their corresponding UI components.
I can even envision a modular plugin rackspace as being shareable in the community.
A comparison written by Gig Performer has Gig Performer on top.
I wont attempt to go over that bit by bit, but some of Cantabile’s demerits are misleading, incorrect, or out of date. I will, however, take strong exception to “variations” Cantabile’s linked racks are much more powerful than GP’s variations.
I think that jwarna summed up the problems with GP racks pretty well. For me, I see complicated racks per song or extremely complicated racks for multiple songs. Cantabile is much more of an object-oriented process.
I was experiencing an issue with recalling SWAM presets in Cantabile. That’s what led me to get evaluation copies of Camelot Pro and Gig Performer. Neither had the SWAM problem. Camelot Pro does a nice job with graphics and scaling. The first time I could actually read Amplitube on my laptop without making temporary display settings. And multiple simple racks per song. But too simple. Non-linear wiring is apparently not possible. Though as a noob, I might have missed something.
There are definitely things I like in GP, but the rack complexity is a deal breaker. For me, YMMV.
Tonight I went back to Cantabile and figured out a simple work-around for my SWAM issue. I’ll probably follow this thread for a bit, but I think my mind is made up.
No, it’s not like that. The information there is correct.
→ If anybody sees ‘false news’ they can write to me directly and I will update that page (like it says on the page). I’d be happy to correct mistakes if any. I looked in the user manuals of those products.
