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

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!

3 Likes

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.

Thanks!

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

I’ve ended up adding this on Sound Radix branch.

Would be nice if JUCE team could do similar on JUCE6.
Due to Ableton being picky, this adds ability to set explicit ‘intention’ of change.

Bonus: you can update preset name for deprecated VST2 :slight_smile:

3 Likes

Guys - can someone actually fix this in the main repo :slight_smile:

2 Likes

btw, our fix works well :slight_smile:

I did miss the hosting side so some audioProcessorChanged needed to be add to plug-in hosting and JUCE demo code. but our QA is happy and it’s nice being able to be explicit for what has changed.

We are also very much interested in a fix on the JUCE master!

Yes - please fix this. I can cross something off my JIRA if you do without patching JUCE again.

And as we all know, closing JIRA tickets saves kittens from dying.

4 Likes

Yeah we’ve observed this too. An easy fix would be great without needing to use sr’s branch.

If anything, Ed’s tab number has only increased in the last few months, so I’ve gone ahead and merged a fix. Thanks @ttg for posting your patch, I ended up going with a similar approach.

4 Likes

First of all, thanks reuk!

But I just discovered that the fix does not send audioMasterIOChanged to the host when details.latencyChanged == true. This way, Ableton Live (and probably other hosts) will completely ignore the changed latency! VST specs require a plugin to send audioMasterIOChanged when latency changes (there is a comment on the ioChanged() member function in AudioEffectX.h in the original VST2.4 SDK).
Surprisingly, its actually audioMasterUpdateDisplay that disables automations in Ableton, so the best (still sub-optimal) solution would be to omit that when only latency changed.

This fix made it kind of worse, as VST plugins are now entirely unable to change their latency!
(Haven’t yet checked AU and other formats.)

I’d say, HostChangeUpdater should keep an atomic flag of what changed, and evaluate that in the update routine. As in the Sound Radix patch.

Thanks for reporting. I’ve pushed a fix for this issue here:

Please let us know if you encounter any further problems.