AudioProcessor::setLatencySamples() disables automation in Ableton (vst & au)


#1

Hi,
When you manually set a plugin parameter in Ableton, the automation for that parameter disables. You have to press the button “Re-Enable Automation” to follow the automation again.
If I call setLatencySamples() in my audio processor and the value is changed, the automation also gets disabled.

It happens for AU and VST on a mac 10.12.5. I’m using juce 5.1.1 .
Is this a bug?

thanks!


#2

We’re also seeing this bug in our plugins. After investigating a little, we narrowed it down to AudioProcessor::updateHostDisplay(), which calls audioProcessorChanged().

In the AU wrapper, this then calls PropertyChanged() for a number of properties, even though latency is the only thing that changed. Commenting out line 1020 of juce_AU_wrapper.mm fixes this behavior: PropertyChanged (kAudioUnitProperty_PresentPreset, kAudioUnitScope_Global, 0);.

Ableton polls the values of all parameters and sets them internally when notified that a preset change may have occurred. This marks all parameters as “manually updated”, even though the value has not actually been set by the plugin, and therefore the automation is disabled because it is overridden by the “manual” setting.

In the VST wrapper, the specific cause isn’t as easy to see. Commenting out hostCallback (&vstEffect, hostOpcodeUpdateView, 0, 0, 0, 0); fixes the problem, but by doing this we also probably stop informing the host of the latency change. There must be a way around this, since we’ve tested other non-juce plugins in Ableton and they are able to change the latency without disabling automation.


#3

Any info on this? This has the potential to ruin customers’ bounces because it could silently disable automation for the bounce only.


#4

so I guess the issue arises when you call setLatencySamples() (or updateHostDisplay()) from the audio thread right?
If you call it from the message thread it’s all fine?