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

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?



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 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.


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

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?

Anyone get anywhere with this? We also have a plugin which we called updateHostDisplay from and yep … on Windows and Mac Ableton seems to pop out of automation mode for no good reason …

1 Like

Do you call updateHostDisplay from the audio thread? I think that if you call it from the message thread you should be fine

I think we would have been calling it from the message thread…!

(sure looks like

Juce team - is there any chance of a fix for this please?

We have a pitch shifter plug-in where we need to call setLatencySamples() when the shift mode is changed. Yet in Ableton Live, this always causes Live to be thrown out of automation read, and for every parameter to be written as automation to the current track, if done when in record.

We think this function needs to get better information from the processor on what changed, and then make fewer property changed callbacks to the AU stuff:

void audioProcessorChanged (AudioProcessor*) override
    DBG("AU: sendAUEvent audioProcessorChanged");
    PropertyChanged (kAudioUnitProperty_Latency,       kAudioUnitScope_Global, 0);
    PropertyChanged (kAudioUnitProperty_ParameterList, kAudioUnitScope_Global, 0);
    PropertyChanged (kAudioUnitProperty_ParameterInfo, kAudioUnitScope_Global, 0);
    PropertyChanged (kAudioUnitProperty_ClassInfo,     kAudioUnitScope_Global, 0);


    PropertyChanged (kAudioUnitProperty_PresentPreset, kAudioUnitScope_Global, 0);

Hello … is there anyone from JUCE here? :slight_smile:

Tom is on holiday. Ed has 150 browser tabs open with forum posts to answer and he’s working his way through them…

1 Like

150… How much RAM is that using?

1 Like

Cheers Jules!

My wife regularly has 150 tabs open in Chrome, she keeps everything she’s interested in open all the time … I have no idea how that works because each tab heading is about 5 pixels across … it’d drive me nuts!


I think I might have been exaggerating a bit there, but he does have a lot of tabs open…

Actually, I’m just writing some code to fix this at the moment. I don’t know whether you’ll like it … the choice is between a new method in AudioProcessorListener or a boolean flag like this:

void audioProcessorChanged (AudioProcessor* processor, bool latencyChanged) override;

Or an even fancier more granular set of flags to audioProcessorChanged.

If you’ve got a preference I can send you a drop in patch if it works…

I think the right answer is probably AudioProcessorListener::latencyChanged() = 0;

Anything new? since this 1year old and I’m in a bug-squashing hunt.
Would be nice to know if I’m missing something or each developer implemented some workaround on their own codebase.


1 Like

Did you ever applied it? I have yet to think of a simple way setting latency without getting into:

From the method above I thought about doing an int instead of bool that will indicate which events changed (latency/preset/etc) so it’ll only use relevant properties/callbacks.

Well, I think we patched it for one of our plugins but I don’t remember if it was ever fixed in JUCE.

Maybe Ed still has those browser tabs to work through :slight_smile:

1 Like