One of the things I found most convenient with Kore 2 and MainStage 3 was the ability to send program change commands directly to plug-ins, so that any plug-in capable of receiving them would respond. In Kore, it was simplicity itself. In MainStage it was largely undocumented, but I found a way to map MIDI controlled PG assignments to a channel strip’s plug-in. Is something like this possible with Gig Performer?
Here’s a scenario. I’ve got a rackspace containing a block with a synth plug-in. In the course of a song the synth’s patch is advanced 9 times from its starting point, using a MIDI CC controller mapped to the ‘next patch’ function. However, I want to have the initial patch come up each time I call up that rackspace.
Another example would be sending an initial expression pedal MIDI command of 127 to a block, so that I don’t freak out at the absence of an expected sound because I’d used the pedal to fade it out and it retained its last setting.
BTW, thanks for a really great product and just as good responses to my questions. Have used GP for two live shows, replacing MainStage and it has performed flawlessly. Slowly beginning to port over the far larger Kore 2 performance patches so I can again have one host app that does it all.
General comment — I think you may be trying to be too MIDI centric. See below for more details.
I found a way to map MIDI controlled PG assignments to a channel strip’s plug-in
Midi program changes that are not associated with any rackspaces can be passed through to plugins. It's an option in Global MIDI but this is not necessarily the best way to do things.
I’ve got a rackspace containing a block with a synth plug-in. In the course of a song the synth’s patch is advanced 9 times from its starting point
Instead of doing this, create 9 rackspaces, each one configured for the appropriate patch. Then just switch rackspaces. Or, create 1 rackspace with 9 instances of the plugin, add a gigrack widget for each plugin that controls the BYPASS option of the plugin (or if each plugin goes to its own gain control then you could control the MUTE of the gain control) and then each variation would have the appropriate buttons set so that only the desired plugin is unmuted (or NOT bypassed).
However, I want to have the initial patch come up each time I call up that rackspace.
If you feel you MUST use MIDI, then you could use a MIDI Output block to send out an initial program change when the rackspace is activated. That program change would be sent to a Mac IAC port. You would then create a Midi In block associated with that same IAC port, and connected to your plugin so that the "incoming" program change would be immediately sent to the plugin. (Cute trick, huh:-)
Another example would be sending an initial expression pedal MIDI command of 127 to a block
Again, this seems very MIDI centric. Instead, create a gig performer widget that is associated with the actual parameter that you want to control from your "expression" controller and control that gig performer widget with your expression control. Then use the "Recall value on load and on activate" options for the widget to set whatever initial value you want when the rackspace is selected. You can also change the widget mode from Jump to Catch so that if your physical pedal is not in the right place, moving it will have no impact until it reaches the current value of the widget.
Will readily admit to being MIDI centric, it’s how things have been done for a long time, though I’m certainly willing to ‘think different’ to accomplish a task. Last night, I implemented all the suggestions you listed above.
Putting an instance in each of 9 rackspaces. Ehm, does the job OK, but moving 9 rackspaces instead of one when reordering a set can be unwieldy. Putting 9 instances in a single rackspace and using variations to assign bypass or mute was more agreeable and actually worked quite elegantly for my purposes.
However, both of these solutions are situations where I really must be convinced to think different. I can’t get around the fact that using 9 instances instead of one that could do the job increases both the memory footprint and the load time of the gig. Though I embrace the idea of using as many elements as I need for the job, memory is finite and I wonder how soon I might bump its ceiling. My working gig is far from complete, but takes longer to load than either the MainStage concert it replaced or the KORE set that I’m working toward replacing. Coming from an audio game development background, it was drilled into me that resources, memory and space were to be used as efficiently as possible. Load times for the gig are usually not an issue… unless the app crashes during a set (all my previous ones have at one time or another) and relaunching and reloading an app always seems to take 20x longer than normal when in front of an audience that paid to see us. Not to mention the humiliation factor. So that’s the big bugaboo I need to get past.
Regarding your last suggestion with widgets and expression control. Bullseye! That approach gets me the exact result I wanted with a minimum of fuss. Thanks!
Not really — the whole point of host automation was to get away from MIDI concepts. Mainstage was in fact one of the first programs to abstract away MIDI from plugin control (which, by the way is why MIDI control in Mainstage was largely undocumented)
----it’s how things have been done for a long time
If your background is software development then it should also have been drilled into you that premature optimization was the root of all evil
----Coming from an audio game development background, it was drilled into me that resources, memory and space were to be used as efficiently as possible
Obviously that depends on your setup but remember that plugins are essentially shared libraries so the code is shared, only the data is separate so unless you’re loading tons of samples, you’d be surprised what can be loaded. Also, if Predictive Loading is an option for you, then you could have a gigfile that, if loaded all at once might take up 50Gb but with Predictive Loading you might only use 2-3Gb total and only a few rackspaces would get loaded up front as well. Lots of options.
----memory is finite and I wonder how soon I might bump its ceiling
----Load times for the gig are usually not an issue
As you might guess, the idea of using whatever and however many of whatever to get the sound and not worrying about resource usage goes against my previous experience in resource management, but as a sound designer the prospect is appealing and liberating. I appreciate your guidance and patience in getting me through this realignment and am perfectly willing to pile on the plug-ins like a bulimic at a buffet as long as Gig Performer doesn’t barf.
