I tried to delay the first process() in the VST3 wrapper, before the parameter changes are updated, to reconstruct the issue.
I think the situation happens when there is a non optimal timely interaction between initialising the plugin with setStateInformation setting the parameters and the first audio call back with its processed parameter changes.
First I thought the problem is because I reconstruct the parameter in setStateInformation via setValue() (which at least worked for the last 20 years) instead setValueNotifyingHost ()
After replacing it with setValueNotifiying host the situation is better, but sometimes there still will processed Parameter changes with the initial parameter value ??
I suspect that these come from these suspicious cachedParamValues?? procedure in the vst3 plugin format
cachedParamValues.ifSet ([&] (Steinberg::int32 index, float value)
inputParameterChanges->set (cachedParamValues.getParamID (index), value);
the I looked into CachedParamValues which uses some kind of FloatCache?!? wtf
I think there is some kind of concurrency problem in there but I cannot name it because its to confusing.
Fact is, setValueNotifiying not magically changes all cached parameter states inside the host or plugin, can that be?
@reuk I tagging you here, because I see that that you added the FloatCache. My instinct tells me that something is wrong here, but i can’t prove it.
BTW: I don’t have a example how to securely reconstruct the problem, you might want to try to add a delay before the first processed parameter changes in the wrapper, and applying the plugin state at the same time