Hey all, can anybody help me out with enumerating all of the possible ways that my plugin could be communicating to the host (Live 10) that a new parameter value is/needs set?
Something my editor is doing randomly (maybe 50% of the time) causes live to hit the static void setParameterCB (VstEffectInterface* vstInterface, int32 index, float value) callback twice in immediate succession, first with the value I wanted to set, then with the value my parameter was at beforehand. So my parameter change is immediately clobbered with the old value. This only happens when the parameter change comes from Live (i.e. automation).
I’ve dropped breakpoints just about everywhere I can imagine (all over the VST_Wrapper, AudioProcessorValueTreeState, AudioProcessor::Parameter, you name it), and none of them get hit in this scenario where Live sends my plugin a parameter change and then immediately sends another one. I’m sure, however, that my editor is to blame, because I can never reproduce this when the editor is closed.
Unfortunately these calls from Live come on a thread that has no valuable stack trace, and I can’t find the instance where my editor/APVTS convinces Live to send the change again. Where can I possibly look here??
Yep, either directly or through an AudioProcessorValueTreeState::SliderAttachment. However, neither path is being executed during this scenario, so there must be some other way in which I’m notifying Live to send another parameter update.
Sorry, what to be more clear - is there automation on the track and is it set to read that automation? If the host is sending automation data when you’re trying to change the editor (without setting automation to “write” in the host) then you’re going to get that kind of problem.
I got unexpected values from live ten, when i set multiple parameters without proper begin & and end change gestures for each parameter. For example, I had an interface component that when clicked may update 5 values, this bug happened when the 5 values were set without a begin & and end gesture message for each change.
If you haven’t already, you may try to add a breakpoint or DBG() in getParameter() to see when is it that the host grabs the spurious value that afterwards is used for the wrong setParameterCB().
While that is not a direct solution to your problem, perhaps knowing when the value is obtained gives more insight at why it is grabbed in the first place. Maybe it happens at regular intervals, or when the DAW also grabs snapshot of the plug-in state for auto-restore of sessions… who knows.
In addition, consider the possibility to tweak your getParameter() in order to always return a different value, so that you can easily follow which exact invocation gives the value that is later used for setParameterCB()
@Jake_Penn that certainly seems like it could be getting me right now. I’ll need to dive in more here– did you ever have a situation where not communicating a begin & end change gesture caused weird parameter overwrites even after deleting & opening a new instance of your plugin? I’m currently seeing that, wondering if Live is holding lingering notions of parameter change transactions somehow.
@yfede Great idea. Let me put some time into that and report back
Yeah for me it was the same as this thread linked above. It seemed without the begin & eng change gestures, live would get a parameter change notification, and then loop back and call setParameter on the wrong parameter ID with the value. I messaged ableton about it and like the thread above they said it was a bug which had been resolved.
I solved my case by not notifying the host of the parameter changes, in my case of one UI component changing 5 parameters, I didn’t need the host aware of that change, or for example, want to have those parameters pop up in the automation lanes in the DAW.
So i guess you could try updating, set the parameter on the value without notifying the host, or add clear beging & end change gestures to every parameter change
I’ve tried surrounding every parameter change call with a begin/end change gesture, as well as explicitly removing every begin/end change gesture call, no dice. Still seeing the issue. I also don’t think this is a Live bug. I’m on 10.0.5 and I suspect way more people would be experiencing this if it were on their end.
I dropped a debugger in getParameter to see when it is that Live claims this value, and it only gets hit when the plugin is opened, at which point my parameters seem to work fine when changes come from the host. It’s only after something goes on in my editor that things start messing up, and there are no calls to getParameter in that time.
So I’m mostly just scratching my head at this point. I’m sure it’s something in my code, but I’m at a loss for how to debug it correctly. I do some Component teardown / construction when the value tree changes and it generally seems like if I comment out that part of the code things work ok. But I can’t imagine why that would cause problems. I’ll report back if I come up with anything
Interesting new find– so my PluginEditor.cpp responds to ValueTree changes from the APVTS that I use to manage my parameters. My valueTreePropertyChanged callback checks if the param id is one of a couple that require tearing down or creating new Components in the GUI Component heirarchy. If the param id is such, it kicks off a method to construct those new Components, remove the old ones, etc. I’ve just found that if I delay this call (i.e. inside valueTreePropertyChanged I have a Timer::callAfterDelay(200, [this]() { updateComponents(); }), everything works as expected (minus my gui being slow to react).
I’ll dig into that more but wanted to share in case that sparks any ideas over here
Getting back to this bug after ADC… I’m fairly confident that the problem arises from a scenario where, in response to a parameter change (valueTreePropertyChanged callback), I want to construct a couple new Components and swap them into my editor in place of other components. That bit of code looks something like this:
parent->addAndMakeVisible(other.get());
other->grabKeyboardFocus();
original = std::move(other);
parent->resized();
Here, original is a std::unique_ptr to an existing visible component, and other is a std::unique_ptr to my new Component that I want to swap in place of original. I’ve also tried this order of operations:
parent->removeChildComponent(original.get());
original = std::move(other);
parent->addAndMakeVisible(original.get());
parent->resized();
I haven’t quite figured out why this would be the root cause, but if I comment out these few lines the issue disappears (and obviously my editor stops showing the current state correctly). Is there something about construction/destruction and addAndMakeVisible/removeChildComponent, or the respective order of operations here that I’m not seeing?
