I was excited to see StudioRack V14’s new VST3 support. Well done! Unfortunately, and I vetted this with Waves tech support, it reverts to Native mode when using both SoundGrid-compatible and SoundGrid-incompatible VST3 plugins within the same StudioRack V14 instance. This means more than one StudioRack V14 instance is required when one wishes to use both SoundGrid-compatible plugins and SoundGrid-incompatible VST3 plugins on a DAW track. One would operate in SG mode and house SoundGrid-compatible plugins; the other would operate in Native mode and house SoundGrid-incompatible VST3 plugins.
With respect, Waves should make this clear in its advertising, especially since it is marketing StudioRack as a channel-strip equivalent. With two instances of StudioRack loaded in successive DAW track insert slots, the gain-staging dependencies between them and, more importantly, the SG/Native plugin selection both to best meet a track’s needs and to optimize CPU performance becomes a bit counterintuitive and diminishes ‘channel strip’ workflow.
I do not know if this is possible, but it would be fantastic if StudioRack could be implemented across multiple threads along different process IDs with the ability to dynamically assign SG vs. Native mode operation at the StudioRack slot level and not simply at the StudioRack instantiated plugin level. Call it ‘flex’ mode. This truly would preserve a ‘channel strip’ workflow and allow one to mix and match SoundGrid and non-SoundGrid plugins at will within a single StudioRack instance.