Actually, I’ve been thinking about it, and the thing that’s bothering me is broader in scope. The problem that started this thread is a separate, smaller problem that indeed is solved by the proper use of the update message flag.
If a human moves the slider, sliderValueChanged needs to tell both the host and the filter about it. In this case, the filter must not trigger a change message to the editor because the slider will already be repainted as it should. On the other hand, if the host is automating, the editor doesn’t know to repaint unless the filter tells it to (right?), which means that the filter must trigger the change message. Unfortunately, setParameter lacks any means of communicating whether the change is automatic or manual.
We could try to solve the problem by making setParameter call sendChangeMessage no matter what, and letting the editor figure out whether or not to change the slider value. But then how would the editor know whether the change message resulted from human activity or from the host automation? We could set a flag in sliderValueChanged, but if the human is manipulating a slider while the host is trying to automate it, the editor might attribute the set flag to the wrong change in the filter, and call setValue when it shouldn’t, or not call it when it should, or both.
Another approach might be to have the editor call setValue every time it’s told of a change in the filter. This seems to be right out because setValue would be called twice for every human-caused change.
Perhaps some tricky deriving and overriding would work, but that seems like a whole lot of effort just to make things behave properly. I’m even beginning to doubt whether this is JUCE’s problem. Again, maybe I’m missing something. Am I looking at things in a completely wrong way?