Problems with begin/endChangeGesture() in Ableton Live 10 / AudioUnit


#1

Hello everyone,
we’ve been having a strange issue we can’t seem to figure out. Whenever we load a preset in our plugin in the AU Version in Ableton Live 10, the preset first loads fine, but then after a couple of milliseconds the host seems to set some parameters to strange values. The plugin has 211 parameters that are implemented by a class deriving from AudioProcessorParameterWithID with the ids being Strings in the form of e.g. “/a/oscillator/pitch”. When a preset is loaded, the data is read from a json file and every parameter is set to its new value via setValueNotifyingHost().
The problem seems to be related to parameter IDs, when we enable the JUCE_FORCE_USE_LEGACY_PARAM_IDS Macro, the problem does not occur, but we would rather use the new String ids… Also, if we call beginChangeGesture() on every parameter before loading a preset, and the endChangeGesture() on all the parameters afterwards, it also seems to work better, the problem persists in some rare cases… Calling these functions before and after setting each parameter when loading a preset does not help though, which i find particularly strange… shouldn’t that be the “saner” variant, changing one after the other?
Also there is the problem that if we call these functions, the loading of a preset could be accidentally recorded as automation.

Just to clarify: if i don’t want the host to record automation but set a parameter to a new value, is calling setValueNotifyingHost() without beginChangeGesture()/endChangeGesture() technically the right way to do this?

The VST version works fine and the AU also works in other hosts like Ableton 9 oder Logic Pro X.
Has anyone maybe experienced similar issues or has any idea what could cause this behaviour?


#2

We’re experiencing similar behaviour here. One additional thing that I have noticed is that when the parameters get set again its from the audio thread and as far as I can tell always set to a normalized value of 0. I’ve just updated to the latest tip on the develop branch with no change in behaviour.


#3

So this is a Live 10 bug - just checked and confirmed it’s resolved in the 10.0.3b