04-24-2024, 06:17 AM
I've been evaluating processing/routing options for more-than-stereo mixing with MB-10 (demo mode.) Much of this was started in 32C v9 in conjunction to atmos with the Dolby panner plugin and an external renderer, but I picked up where I left off now that there is an internal renderer at the ready. I've done this sort of thing with many "stereo-only" workstations, just to see what's possible.
Some disclaimers - I'm aware that lots (maybe all) of this is specifically not supported. Plugin failures, crashes and basic incompatibility should be expected, and is not a bad reflection on the team at Harrison. They have specifically said this release is not intended for this type of functionality.
These proofs-of-concept fall into a few basic categories.
Managing multichannel playback of related positional audio.
2-in multi-out signal processing.
Multi-in multi-out signal processing.
Plugins that need to be forced into multichannel modes.
Assistive plugins that load others internally.
Moving an object between two positions with additional changes in character *beyond position) is limited to characteristics additionally automatable - such as rolling a filter off while changing positions. Others may involve two sets of panned objects receiving signals that are modified more deeply and simply cross-faded between the two sets of desired goals. Routing a strip to another strip makes this possible as long as multiple new faders pickup the same signals and process them differently. As far as I can tell, there is not a way for the source signal strip to get to the router source point without going through the fader.
Most multichannel effects plugins I've checked (reverbs, delays) want to determine their multichannel environment when they are added to the strip. This obviously results in "stereo". Some plugins will sense more output pins as they are added and adjust on the fly. Others must be closed and re-opened. In the worst cases the plugins must be de-activated before the pins are added, then re-activated. Sometimes the plugin GUI must NOT be open at the time of the pin adjustments for them to stick. Save your session regularly, MANY of these steps will crash Mixbus. If you don't already, you may wish to enable all AU VST and VST3 for your efforts. In most cases, plugins that are available in all three flavors will definitely not behave the same way under these situations. Some plugins that state a certain track-width functionality may not be able to live up to that stated spec in MB 10.
The good news here is that once you've managed to get these instances working, they only need the extra outputs assigned to additional strips to function rather normally. Several of my tested reverbs can feed all 16 outputs in 9.1.6 mode. I haven't tried more than 16.
So far I've not found anything as simple as multi-mono plugins (Pro Tools wording). These are a good way to save on CPU work.
With CPU-intensive processes, sometimes it's beneficial to commit or freeze or local-bounce. This is not part of the MB design, so I'll work to come up with solutions for this, perhaps doing preliminary work outside of MB-10 then importing processed items. It's unknown (demo mode) if playback audio generated within plugins actually makes its way into the ADM export, even while playing properly in the session realtime.
For plugins that need more than 2 inputs, creating sidechain busses seems to work. I've not worked with more than 8 sidechains per strip yet but haven't bumped into any limitations. It's a shame to use an entire channel strip just as I/O for a plugin. Generally these routes "stick" using the routing window, but on a few instances I've needed to make a change to sidechain source in the pin window first. This functionality is needed to create the I/O setup for multichannel dynamics and similar track-management processes. I've been able to get some of these to work natively, but the plugin is unaware of what's on what track, so some of the GUI labels are incorrect. (L-C-R etc) Chaining multichannel plugins this way seems natively impossible, or at least I have not discovered a way. Sidechains can get 8 channels into a 7.1 comp, with 8 outputs, but another plugin afterwards only has access to the stereo pins from above. The same hurdle seems to make it challenging to EQ the output of a non-stereo reverb without wrapping both into another host plugin. You can eq the individual stereo strips receiving the outputs, but no way to link the multiple controls.
There are 2 assistive items that seem to work with some effort. Blue Cat Patchwork and Plogue Bidule, both can host plugins and allow chaining and processing internally. Both of these come in multiple flavors and many don't work or crash Mixbus. For basic stereo work, both work easily. I've succeeded with Patchwork Synth VST to get 8x16. I've succeeded with Bidule 16x16 VST for stacking 7.1.2 processes together. Patchwork is more intuitive and user-friendly, but Bidule has better flexibility when it comes to predicting the channel layout potential of a plugin before trying and failing. Patchwork has an elegant way to expose plugins from inside back into Mixbus.
Inside these wrapped environments there are easier ways to design mini-plugin configs to suit a task, but it is best to close down the related GUIs if you're working with pin settings, as this can easily crash Mixbus. Once things are operational, things seem to be stable and recall properly after saving. It has been difficult to have the router window, the plugin host window, and the pin window opened simultaneously without crashing Mixbus.
It seems useful to have the "traditional" MB console support processing/summing/splitting processes upstream of object panning. It is unfortunate that enabling Immersive panning defaults to ON for everything in the session, including the groups. I'm sure for some this will be a useful default, but it makes this type of plugin work more challenging. This upstream-downstream strategy also contributes to an already increasing CPU load. Every strip hosting multichannel processes bypasses the EQ/Comp/Gate yet the DSP usage is still there. Basic summing systems would be more lightweight.
So far I've not found a way (in the manual or by trial and error) to forecast if a plugin will allow extra input pins, extra instances, or extra output pins without just trying, and sometimes crashing out.
Aggregating multiple instances of these multichannel items would ideally be able to happen upstream of the groups, but lots of strips with processing at least can accomplish the task.
Lots of fun.
h
Some disclaimers - I'm aware that lots (maybe all) of this is specifically not supported. Plugin failures, crashes and basic incompatibility should be expected, and is not a bad reflection on the team at Harrison. They have specifically said this release is not intended for this type of functionality.
These proofs-of-concept fall into a few basic categories.
Managing multichannel playback of related positional audio.
2-in multi-out signal processing.
Multi-in multi-out signal processing.
Plugins that need to be forced into multichannel modes.
Assistive plugins that load others internally.
Moving an object between two positions with additional changes in character *beyond position) is limited to characteristics additionally automatable - such as rolling a filter off while changing positions. Others may involve two sets of panned objects receiving signals that are modified more deeply and simply cross-faded between the two sets of desired goals. Routing a strip to another strip makes this possible as long as multiple new faders pickup the same signals and process them differently. As far as I can tell, there is not a way for the source signal strip to get to the router source point without going through the fader.
Most multichannel effects plugins I've checked (reverbs, delays) want to determine their multichannel environment when they are added to the strip. This obviously results in "stereo". Some plugins will sense more output pins as they are added and adjust on the fly. Others must be closed and re-opened. In the worst cases the plugins must be de-activated before the pins are added, then re-activated. Sometimes the plugin GUI must NOT be open at the time of the pin adjustments for them to stick. Save your session regularly, MANY of these steps will crash Mixbus. If you don't already, you may wish to enable all AU VST and VST3 for your efforts. In most cases, plugins that are available in all three flavors will definitely not behave the same way under these situations. Some plugins that state a certain track-width functionality may not be able to live up to that stated spec in MB 10.
The good news here is that once you've managed to get these instances working, they only need the extra outputs assigned to additional strips to function rather normally. Several of my tested reverbs can feed all 16 outputs in 9.1.6 mode. I haven't tried more than 16.
So far I've not found anything as simple as multi-mono plugins (Pro Tools wording). These are a good way to save on CPU work.
With CPU-intensive processes, sometimes it's beneficial to commit or freeze or local-bounce. This is not part of the MB design, so I'll work to come up with solutions for this, perhaps doing preliminary work outside of MB-10 then importing processed items. It's unknown (demo mode) if playback audio generated within plugins actually makes its way into the ADM export, even while playing properly in the session realtime.
For plugins that need more than 2 inputs, creating sidechain busses seems to work. I've not worked with more than 8 sidechains per strip yet but haven't bumped into any limitations. It's a shame to use an entire channel strip just as I/O for a plugin. Generally these routes "stick" using the routing window, but on a few instances I've needed to make a change to sidechain source in the pin window first. This functionality is needed to create the I/O setup for multichannel dynamics and similar track-management processes. I've been able to get some of these to work natively, but the plugin is unaware of what's on what track, so some of the GUI labels are incorrect. (L-C-R etc) Chaining multichannel plugins this way seems natively impossible, or at least I have not discovered a way. Sidechains can get 8 channels into a 7.1 comp, with 8 outputs, but another plugin afterwards only has access to the stereo pins from above. The same hurdle seems to make it challenging to EQ the output of a non-stereo reverb without wrapping both into another host plugin. You can eq the individual stereo strips receiving the outputs, but no way to link the multiple controls.
There are 2 assistive items that seem to work with some effort. Blue Cat Patchwork and Plogue Bidule, both can host plugins and allow chaining and processing internally. Both of these come in multiple flavors and many don't work or crash Mixbus. For basic stereo work, both work easily. I've succeeded with Patchwork Synth VST to get 8x16. I've succeeded with Bidule 16x16 VST for stacking 7.1.2 processes together. Patchwork is more intuitive and user-friendly, but Bidule has better flexibility when it comes to predicting the channel layout potential of a plugin before trying and failing. Patchwork has an elegant way to expose plugins from inside back into Mixbus.
Inside these wrapped environments there are easier ways to design mini-plugin configs to suit a task, but it is best to close down the related GUIs if you're working with pin settings, as this can easily crash Mixbus. Once things are operational, things seem to be stable and recall properly after saving. It has been difficult to have the router window, the plugin host window, and the pin window opened simultaneously without crashing Mixbus.
It seems useful to have the "traditional" MB console support processing/summing/splitting processes upstream of object panning. It is unfortunate that enabling Immersive panning defaults to ON for everything in the session, including the groups. I'm sure for some this will be a useful default, but it makes this type of plugin work more challenging. This upstream-downstream strategy also contributes to an already increasing CPU load. Every strip hosting multichannel processes bypasses the EQ/Comp/Gate yet the DSP usage is still there. Basic summing systems would be more lightweight.
So far I've not found a way (in the manual or by trial and error) to forecast if a plugin will allow extra input pins, extra instances, or extra output pins without just trying, and sometimes crashing out.
Aggregating multiple instances of these multichannel items would ideally be able to happen upstream of the groups, but lots of strips with processing at least can accomplish the task.
Lots of fun.
h