Well, there should only be one value, that the processor holds. The GUI sends a message to change it, and recieves a notification back if it changes, thus syncing itself. The host automation, if run in another thread, has to send messages as well.
The processor either chooses to consume all changes once it starts rendering or to read directly from the value the others write to. The latter works ok for simple stuff like gain values.
The former model essentially creates two views of the data, one being the parameter values that can be concurrently updated and some internal inaccesible view to the processor. This method is completely safe and scales without problem, and it basically works like a messaging system actually.
[quote=“fxtentacle, post:6, topic:18216”]That, of course, leads to really annoying synchronization problems. What if my user changes a parameter in the GUI concurrently to Pro Tools updating that parameter with setParameter.[/quote]This is handled in every host and plugin format I know of by turning off automation after the host has been notified of a parameter changing from the outside, thus no problem.
Have an internal variable representing the current, and on each process() call (or each 32th sample or whatever) you update a target value from the outside, that you constantly interpolate “current” towards. Usually the automation is lagged one update behind, such that no “guessing” has to be performed.
[quote]On the GUI side I get a similar problem if I don’t use explicit synchronization, in that parameters will flicker in the GUI, for example when the redraw happens after the LR coordinate has been updated but before FR was written.[/quote]To solve this problem you need to use a lock free queue/ringbuffer, where the processor produces values that the GUI can consume as whole.
[quote]Also, my impression is that they are not even trying to make automation precise. For example, here’s a quote from the AAX spec: “any parameter updates from automation will be reflected in this context a little bit ahead of time (~21 ms at 44.1 kHz.)” So as the plugin developer, should I just assume stuff always arrives 21ms too early? Or is that my hint that nobody really cares that much about sample-precise automation?
[/quote]
Just remembered this topic: Automation firing early in Pro Tools 11 - #9 by chkn