I’ve now got so much MIDI firepower that I’m unsure how to use it! (Not that I’m complaining.)
Preface: When sending MIDI to multiple instances of Gig Performer, the typical solution is to create MIDI loop back virtual ports within the ‘Master’ Gig Performer instance via the IAC bus; and pass incoming MIDI from the actual incoming port to the (loopback) virtual port, which can be accessed by the instances.
Question: Must this task be handled by Gig Performer exclusively? Or will IAC Ports/3rd Party Virtual Ports created and routed by other apps be accessible to non-Master instances?
I ask because I will now begin running Bome Network Pro, Bome MIDI Translator, and Multiple Gig Performer Instances on the same machine. All of these apps can create virtual MIDI ports. BNP is the simplest to use (bi-directional named virtual ports show up as core audio ports), BMT is the fastest and most comprehensive (uni-directional ports shunt MIDI through a powerful, extremely fast dynamic MIDI processing engine), and GP is the friendliest in terms of troubleshooting and reverse-engineering. (Visual block-based programming and global rackspaces allow for obvious signal flow and third-party plugins.)
With all the above having been said, I will be searching for the best balance between low-latency, transparent troubleshooting, and full function when configuring the interplay of these three. All three are required in the mix to support the functions I’m working with:
BNP : Required to receive any and all MIDI performance and control data from the band members over the LAN network.
BMT : Required to control Logic Pro transport, which is operated like a multitrack tape recorder running in the background, and to map copies of all performance data TO and FROM a single 16-channel port for consumption by (and playback from) Logic Pro
GP : Required to host all VSTs across several multithread-friendly GP instances, Send patch changes/OSC to MIDI hardware and parameter values to plugins upon song select, and route/process MIDI foot controller data dynamically… allowing each stomp pedal to operate differently on each song as required by the show.
If a ‘typical’ high level config for using these three apps simultaneously even exists, I gather it would be BNP>BMT>GP/LOGIC. This would gather all the incoming MIDI using BNP, Port it into BMT for splitting/merging/translation, Split out a multichannel-stacked port for Logic Pro, and Port the main ‘streams’ out of BMT to a master GP instance, then loop them back to the other GP instances via manually-created IAC busses.
…But is that last step necessary when both BNP and BMT have already created tons of Virtual MIDI ports? Using BNP’s virtual ports directly for MIDI performance data in GP non-master instances (if supported) would retain the use of GP’s Rig Manager, which I love… and remove a single-point-of-failure, troubleshooting complexity, and latency contributor in BMT (Yes, I know BMT is fast… latency is probably not a valid concern.) This would look more like PERFORMANCE DATA>BNP>GP (non-masters); CONTROL DATA>BNP>GP (master) > (GP (non-masters)) / (BMT > LOGIC PRO. )
This would keep the chain shorter and easier to troubleshoot, while relegating BMT to Logic Control/Translation duties only. But is it possible?
I will find out the answer to this on my own eventually… but I have much more time available to type out questions on forums than I do to test my own theories… just trying to make my scant hands-on time more efficient!
Chris