at this point im evaluating Gig Performer. I’m trying to build my basic setup (metal keyboardist) and can’t decide whats the best way to do it.
Shortly said, I want to play around 20 Omnisphere Sounds and 2 Kontakt Sounds. Also, on any MIDI input I want to do some filters and a monitor and on any sound output I want to use my compressor to level the sounds out a bit and monitor phasing.
Now I see some ways to achieve that (and see some benefits and disadvantages of whose i’m not sure):
1. Create a Rackspace for every of the 22 sounds I want to play.
Pros:
Low patch loading times due to smooth transition between rackspaces
Cons:
20 simulatanous Omnispheres and 2 Kontakts in RAM could kill the machine (or I have to enable preemtive loading)
When I want to change the compressor, filter, monitor or phase monitor, I have to that in 22 rack spaces.
2. Create one big rackspace with Omnisphere, Kontakt and the other plugins. Use program changes / CC to switch sounds within Omnisphere and Kontakt.
Pros:
Small, simple and easily understandable setup
Low number of plugins, good for RAM
Only one monitor, compressor etc
Cons:
Heavy loading times of patches
Complicated routing of PC / CC.
3. Create one giant rackspace with 3 Omnispheres and 2 Kontakts. Use Omnispheres MULTI capability to load up to 8 sounds into each omni and do some MIDI channel routing shenanigans, somehow wire channels with the correct Kontakts using variations.
Pros:
Only one monitor, compressor etc
No patch loading times
Cons:
Potential high RAM usage due to all sounds loaded at the same time.
Very complicated and unintuitive setup.
4. Create 5 rackspaces, 3 with one omni (that contains 8 patches with multi) and 2 with kontakt, each with monitor, compressor etc. Use some MIDI Channel stuff and variations to change between the Omnisphere Multis.
Overall hybrid solution; Medium setup complexity, medium loading times, medium RAM usage, medium number of repetetive modules (monitor, compressor etc)
Am I missing a better way to do it? What would be the best practice, the way the developer intended it to be done here? Am I misjudging some pro or con?
Welcome to our forums… that’s a hell of a question I’m sure someone will be able to give you some pointers. Just want to say that one other consideration you may want to bring in is the CPU usage. If you use your first method (with 22 rackspaces) then the CPU load will be much lower because inactive rackspaces typically do not consume CPU cycles.
Switching sounds within Omnisphere and Kontakt could work, but the load/switch times will not be the same as if everything is pre-loaded (as you already pointed out).
I’d personally vote for the separate rackspaces especially if you later start using the Songs and Setlist features with predictive loading when’re GP will be able to figure out songs you’ll play next and pre-load everything in advance.
Global effects processing is on our TODO list and is high priority so once we have that you’ll be able to have single place to control your effects for all rackspaces.
Those are actually quite excellent hints, CPU should definitly be taken into consideration!
I’ve actually started with the songs and setlist feature and learn from there (coming from brainspawn forte), so that might be totally viable.
Thank you very much
Small question: Before you implement global effects, why not implement modular rackspace nesting? You have those fancy well defined one-input one-output rackspaces anyway, why not allow them to be used within a rackspace as one “virtual instrument” / “module” / whatever?
What I’m imaging is that I then could just make a rackspace with my global modules wired in any way, plug them to a subspace which is interchangable via variations. Or anything like that
There are many considerations to take into account when doing this. Some of those include handling of our OSC support, MIDI mappings, Widget mappings etc…
You’ll note that in GP you really bring forward any plugin parameters you need and connect them to widgets (knobs/sliders etc.). you then control these widgets via MIDI or osc. This indirection is something that (I think) was not available in Forte, but it is very powerful.
Thanks for your suggestions though … hope you’ll find the right approach for your environment and playing style.
I was just thinking the same thing. The redundancy of having to replicate that setup every time is tedious and seemingly unnecessary. If you could create a user defined custom input/output block module that be inserted in a single instantiation move, it would improve work flow tremendously!!
Have this “multi block”:
be able to have as many separate input/output MIDI (and or audio) blocks as the user desires,
have the parameter setup for each of the modules be remembered,
have a bypass toggle control for each of I/O modules if desired
have a user definable “default” that loads automatically
use GP’s usual block load and save feature to have predefined alternate setups.
I would LOVE to have #4 implemented right away.
I also look forward to having a global effects section of GP. This key feature would allow easy tweaking of the final output. I would LOVE to have a 31 band graphic EQ and some compression/limiting between my audio output block and my audio interface1
I’m sure someone will be able to give you some pointers. Just want to say that one other consideration you may want to bring in is the CPU usage. If you use your first method (with 22 rackspaces) then the CPU load will be much lower because inactive rackspaces typically do not consume CPU cycles.