Issues with new "low latency monitoring" in Studio One 3


#1

It looks like, starting with version 3.5 of Studio One, Presonus has introduced a new “low latency monitoring” feature in their DAW, which is causing severe problems to several plug-ins we’re developing, because of the way it is implemented (see below):

To reproduce, grab the latest version of Presonus Studio One (3.5.2 at the moment of writing) and (refer to the image below):

  1. Create a new empty project and add an audio track into it
  2. Insert your plug-in into the track
  3. Enable the input monitoring for said track
  4. Enable the “low latency monitoring” feature by clicking the “Z” at the bottom of the output fader

What happens when step 3 is performed is that Studio One creates a second instance (called “slave”) of your plug-in, that will do the processing from then on until the “low latency monitoring” is disabled.

The “master” instance (the one originally created when you inserted the plug-in) is not destroyed: on the contrary, it is kept very much alive, because the UI for your plug-in (the editor), is still connected to that one.

No editor is created for the slave instance which, in turn, by default is kept in sync with the “master” only by mean of automated parameters.

So, for example, suppose you turn a knob in the editor. The corresponding value in the master instance is updated and, in simple plug-ins, it is reasonable to assume that an automation value is also adjusted. That change in automation is caught by Studio One and replicated to the slave instance, which eventually updates the algorithm that’s actually used for processing.

It’s easy to see how this approach cannot work for more complex plug-ins, where several aspects of the processing algorithm are not easily captured by automation: customizable impulse responses, structure of rearrangeable internal sound chains, etc. all fall in this category.

An action in the editor that acts upon one of these aspect is going to be correctly propagated to the “master” instance, but because it does not affect automation, the “slave” instance is going to completely miss that, and the audio of “master” and “slave” will start to diverge.

For those cases, Presonus has released few days ago (end of September) a set of plug-in extensions for the formats they host (VST2, VST3, Audio Unit) which should be used by the “master” instance to keep slave instances in sync.

Obviously, implementing those extensions requires manipulating the JUCE code for wrappers.
Also, I expect this to become more of a common issue the more time passes and this “low latency” feature gets known to the public.
Only a couple of weeks have passed since its release and we’ve already received a support request about it.

Is there any chance something will be implemented in JUCE to cope with this?


#2

Please assure me this is opt-in for plugins ?


#3

You wish.

We’ve been hit by this on plug-ins that haven’t been changed in months.

We did nothing at all to declare support to this mode in our existing plug-ins, and I’m not even sure it’s possible to opt-out using the provided plug-in extensions.


#4

Ah Ah. Their bug then because this is just a false assumption that you should be able to do that.


#5

Yes… but until a workaround is found, it’s our plug-in that looks like malfunctioning, not their DAWs


#6

Don’t negotiate with kidnapper :slight_smile: