That flicker is the host automation batteling with the values you are sending to the host.
Before you can send a setValueNotifyingHost() you must tell the host, that the user wants to take control by calling beginChangeGesture(). The host will now decide, depending on the automation setting, if it accepts the user value (on write or latch), or if it ignores it and keeps using it’s own value (read).
When the user lets go of the control (mouseUp()), you call endChangeGesture() to return tontrol to the host.
In this scenario you don’t need to know if an automation is happening, it is all in the responsibility of the host.
Btw. using the hiResTimerCallback() is still the wrong approach, because it is asynchronous from the audio thread.
The parameter sends a callback to its listeners (Implemented in AudioProcessorParameter, but you need to denormalise the parameter to the proper range yourself).
Your Slider would need to keep track, if the user has the mouse pressed and in that case ignore the value.
When the user lets go of the slider, you would need to get the actual value from the parameter and set the control accordingly.
IMHO that is all handled with the SliderAttachment, it saves a lot of typing and bug-fixing.
In general, my set up seems to be okay, i was already using “begin and end Gesture” and the denormalising is also fine.
I am not using SliderAttachments, because I am not actually working with Sliders. The automatable float parameters represent the plugin’s output, which is constantly generated by an combination of different values and some internal behaviour. It is constantly changing the float parameter value. Shell I call begin and end gesture for each change?
I think, as you noted, the problem is the hiResTimerCallback(), which is asynchronous from the audio thread and makes it flicker. So I should call it from a different thread… (is there some kind of fancy overview or diagramm to understand the timmings of the different threads and callbacks?)