Will this change also makes its way into the dev branch?
Probably not. This feels like a relatively high risk alteration, and if there will be any associated non-backwards-compatible behaviour this will be much easier to handle in JUCE 7 onwards.
thank you @reuk . I’m experiencing the Ableton issue. Will test the juce7 branch.
Thanks for getting to this - it was really important ![]()
At least from looking at this commit: (but I might’ve missed something)
It looks similar to JUCE_STUDIO_ONE_COMPATIBLE_PARAMETERS where it can basically be behind a flag.
Speaking for myself (not necessarily the rest of the team), I’d much prefer to avoid adding more compile flags to switch behaviours on and off. These flags add another dimension to consider when reporting and reproducing issues, and they make maintenance much more difficult - we can’t realistically test all the different combinations of all of the flags on CI, and it’s easy to accidentally introduce syntax problems when modifying heavily ifdefd code. Additionally, using preprocessor flags increases the risk of ODR violations, if the same headers are shared across multiple translation units built with different flags.
The main scenario in which I’d consider adding such a flag is if the new change is shown to cause backwards-compatibility issues for plugins. In this case, there may be a legitimate reason for developers to opt-in to the old behaviour. At the moment I’m not aware of any such issues, so I don’t think a flag is necessary. If you find any problems like this during testing, then of course I’ll reconsider.
Thank you for explaining the complete rationale of favouring this to be a JUCE7 feature.
Is this really specific for AU? I could reproduce this with VST3. After reloading a project the automation is greyed out. Whats Ableton’s view on this topic? If it’s a bug in Ableton, it should be fixed there.
Currently I am not using the latest JUCE7, I am still on the latest JUCE6.
Has there been any update on this topic?
This also happens with the VST2 version. This is not platform-specific. JUCE seems to make parameter changes during “setChunk,” and that is problematic.
We also have more and more reports of our plugins disabling themselves completely on Pro Tools (AAX). So, maybe this is a similar issue?
What does “disabling themselves” mean in the context of Pro Tools? Bypassing or something else?
So, according to that customer, the track “can not play”
Here is his description:
If I have used Nexus in pro tools close the session and the day after it sometimes happens when reloading that the nexus cannot play.
Sometimes I have to delete Nexus in protools and other times I have to delete track and then create a new track with Nexus.
He also attached this screenshot as “proof”:
I’m not sure what that screenshot is supposed to show us.
