Please excuse me for writing such a long request for advice and help below.
I am considering Gig Performer along with a couple of alternative real time performance management programs for my home studio setup. It consists of two hardware synths (a Korg M3 and a Korg PA5X) along with a late model M1 MacBook Pro. On the latter, I primarily use a great plug-in hosting program called Unify which allows me to layer pretty much any VST or AU plug-in that I own (e.g. Omnisphere, Kontakt, PianoTeq) and then apply audio and MIDI effects in unique ways to create compelling new sounds. Unify allows me to save these new multi-patch sounds as presets using a naming structure that is based on the well-established program change control naming convention that uses the CC#0 and CC#32 parameters, making it very easy to call up these patches remotely. And not surprisingly the two hardware synths’ internal presets can be selected remotely using the same program change convention.
One of the most basic things I’d like to do in Gig Performer is to employ a device like a Stream Deck or an app like TouchOSC or MIDI Designer Pro to create a set of virtual pads to which I could assign my favorite combinations of sounds among the three instruments. My understanding from an initial read of Gig Performer’s documentation is that it discourages configuring GP to issue direct program control commands to plug-ins and external instruments, and instead to create individual ‘rack spaces’ that are hardwired for each specific combination of patches one wants to select. But considering that there are at least a dozen or so patches from each of the three instruments that I would consider combining into a set of favorite combinations, I would think that the resulting number could give rise to an unwieldy number of rack spaces that I would have to individually create. What I was wondering is if it would be possible instead to set up a single Gig Performer rack space that contained three ‘program change’ widgets, with each widget responsible for issuing a program change parameter to one of the three instruments. Then I could simply assign a desired combination of just those three program change parameters to a pad, rather than have to create an entire rack space for each such combination.
I understand that there are good reasons cited for avoiding issuing direct program changes. But am I misinterpreting or misunderstanding how best to accomplish my objective above using GIg Performer? Or am I simply being overly concerned about creating this potentially large number of rack spaces?
Any advice would be greatly appreciated as frankly I am strongly leaning towards Gig Performer as the most desirable solution overall for helping me manage my setup.
In the Gig Performer world, you can do everything however you like and prefer. There are some approaches and best practices, but of course you can do whatever you want.
Why best practices: because they seem to improve the stability and manageability of your setup in the long run.
Over the time you see what workflow is the best for you. For example, there are users that don’t use Setlists at all (Setlist view). Other users use one big rackspace along with the Global rackspace (global effects). There are users that use the Global rackspace only (e.g. CCM use cases). Some users don’t use (say) the Rig Manager at all. It’s Gig Performer that allows you that flexibility, and then it’s up to you to see what works for you the best.
Gig Performer and its ecosystem is very well documented with a bunch of tutorials and guides → Gig Performer Resources
–
Many exciting beta features are in the works and being tested, this community forum is a wonderful place, so it seems that Gig Performer is really a ‘no brainer’ today
Thanks very much for this very helpful reply. I recognize now that the recommendation to minimize use of program change events is more of a ‘best practices’ recommendation and not due to any limitation in Gig Performer. And I also appreciate the very helpful links that you provided.
In the interim, I did further investigation of the alternatives to GP and I am now convinced that it is the way to go. I’m very impressed by the depth and breadth of its functionality, compatibility with other sofware, flexibility and the way it minimizes the demand on computer resources. Also very impressed by the degree to which you are constantly updating the program based on user feedback. But possibly the most important factor is the level of support provided both by your company directly and by your user community across using a variety of Web vehicles. I won’t name names (though it will be clear which product I’m referring to), but the alternative platform I was most closely considering pales in comparison to this level of support, not even offering a user manual to guide one in the learning process.
So I will very soon become a new member of the GP community. Though I hope you don’t mind me possibly frequently turning to this forum for support!
Well, it’s an important best practice - if your goal is to perform live and have instant access to different sounds, even in the same song, then you don’t want to use program change messages because there’s no guarantee as to how long any particular plugin will take to switch over.
While we do encourage people to first check our online documentation, which is very thorough, the whole purpose of our community forums is for users to share info, ask (and then later answer) questions
^^^^ Not to give a second homily David but, THIS, all VST users who want to only use PC to change VST patches. Only way possible with an external synth. Not guaranteed the best approach with a VST.
The word David punches is INSTANT
[pretends nobody can see singed smart-guy eyebrows]
blog and how-to articles are based on the pulse of this community (and other FB groups and forums). - also if some topics are not clear in the User Manual, we update it.
