I use a Linnstrument as my MIDI controller, and I have it split so the left have uses channels 1-8 and the right half uses channels 9-16. (Linnstrument is an irrelevant detail here. The same holds for any other keyboard which can split, or just having two separate keyboards.)
Then I have 4 VSTs I like the sound of, and I want to easily switch which sound is connected to the left hand and which is connected to the right hand. How would you do this with Gig Performer? (Is this out of scope for Gig Performer? I want this so I can easily play around for myself. Not because I need this flexibility when actually performing.)
One possible solution is to have a MIDI route component which I can feed the MIDI signal into, has a bunch of MIDI outputs, and in the panel I can control which of the outputs is currently active. I don’t think something like that exists though.
Bonus points if the solution easily extends to 8 or more VSTs. (Creating 44 variations is doable. 88 is turning into madness.)
More bonus points if the VSTs that aren’t currently active aren’t running so they don’t use CPU.
Maybe what I really want is two Gig Performer instances. Then the two hands can’t share the same VST, but then Gig Performer’s rackspace/variant system would fit nicely.
This has the downside that I have to duplicate plugins that are available to both hands.
Your scheme (and then enabling inputs instead of plugins) means I don’t have to duplicate plugins that are shared between hands, but then all plugins are always running. Which is unfortunate for some of them, like the GSi VB3 which uses at least 10% of my CPU even if it’s not doing anything at all.
Both these schemes involve a fair amount of steps to add a new plugin. It would be great if all I would have to do is add some wiring, and have the panel adjust automatically.
I don’t understand — if you use multiple MIDI In blocks, you can control which ones are one - you don’t have to have multiple instances of the VST plugins?
Also you can use GP Script for even more control, such that you could easily bypass the plugins that you don’t want to be active.
One issue I’ve run into with using Bypass to turn plugins on and off is that they don’t always behave exactly as you want.
e.g., if I hit the button to bypass the MIDI in while my foot is still on the sustain switch, or I still have notes held down, they end up stuck on when I un-bypass. Different VSTs seem to react differently to being bypasses as well.
My solution to this is putting MIDI filter blocks in front of the VSTs that I want to be able to turn on and off. My filter blocks are set to block Note On events. When the filters are bypassed everything gets to the VSTs. When the filters are un-bypassed the Note On events get blocked, but sound tails will continue to play and they still pick up sustain pedal off, pitch bend, etc.
Hmm, while I could argue that the MIDI In block is doing precisely what it should be doing, i.e. not allowing any more messages through once you bypass it, I’m wondering whether it might make sense to have a new option that would automatically send all notes off when one bypasses.
I think it is doing exactly what it should be doing. I’m not sure you need to build more options into those MIDI in blocks.
My gut says that if you add an option to send note off events on bypass somebody will say “how about one to do xyz” and eventually people will want everything in the filter block available in the midi block. For me, having the filter blocks there reminds me of what I’m doing when I copy and modify a rackspace or just look at it a couple months later.
I also would recommend to do the switching on the MIDI NoteOn side, instead of bypassing the VST instruments.
My solution is to use widgets to directly block NoteOn (!) messages of those MIDI In blocks of splits and layers which should not sound at the moment.
Then you could use variations or songs parts to quickly switch between different splits and layers on all of your keyboards.
The solution of @Vindes is in fact quite similar with same result, at the expense of addidional blocks, for sake of a better overview.
See also this thread:
It seems that @rtwfroody is asking something quite similar.
I never would bypass the whole MIDI in block, but rather switch the BlockNoteOn option on and off.
However, the new option could be a safety means for those who mess around with blocking MIDI In ports. In that case, don’t forget an option to “AllSOundsOff” as NI Kontakt would not react on AllNotesOff for long sounding one-shot samples.
That makes sense. By bypassing MIDI in blocks, and adding scripting on top of that, I can achieve everything I want. It’s a bit more setup than I might like, but I’ll have to live with that.
It would be cool if GPScript could discover all the blocks and how they are linked up, so a single script can adapt to whatever number of blocks and VSTs are present in the wiring. (And if that works, it would be cool if you could use GPScript to generate panel buttons so that process is also automated, and all I have to do to add/remove a VST is change the wiring.)
And in case of errors you have to debug complex code … I like it to keep simple.
Fair enough. Personally I prefer to write and debug complex code over doing a bunch of manual steps. We can easily both get what we want here.
It would be cool if GPScript could discover all the blocks and how they are linked up, so a single script can adapt to whatever number of blocks and VSTs are present in the wiring.
What would that help for?
Then when I add a new VST, all I have to do is update the wiring. As it stands now I’d have to update the wiring, the script to disable VSTs that aren’t accessed right now, and the panel.
It’s another trade-off between writing a complex script or performing a bunch of manual steps.
I can understand that, but the philosophy behind GP is that musicians can do rather nice and even complicated things, without to do the nitty-gritty themselves.
I’m also someone who likes to program and I do not shy away from C, C++, C#, Java, VB, lua, Python, Powershell, bash, etc., so to me gpscript is really easy (as it is obviously to you), but there are a lot of musicians who find scripting hard to understand and just want to create music. And I think serving musicians is the primary goal of GP.
But you’re right making clear what features you think are cool . A lot of people make feature requests and when it serves enough people, there is really a chance a feature request makes it to be implemented in a release.
. A lot of people make feature requests and when it serves enough people, there is really a chance a feature request makes it to be implemented in a release.