When I change a plugin’s parameters using Probabilistic Sound Designer (PSD), the controls for those parameters in a rack panel are not updated. This happens both when randomizing all controls using the “Randomize” button or tweaking individual parameters in the list of controls.
I don’t think this is limited to one specific plugin because changes to controls that are made via the plugin’s UI are synchronized with the rack panel’s controls. In case it may help troubleshooting, I ran into this problem while fooling around with PSD and Gullfoss.
I don’t think that’s going to change — when you change a parameter, the plugin doesn’t reannounce the change back to the host so the host doesn’t know the parameter changed.
Adding logic to do that tracking ourselves is probably complicated and not worth the effort
To demonstrate this, add two widgets to a panel and map them both to the same parameter of a plugin (do not LINK the widgets)
If you now adjust the parameter in the plugin, both widgets will move. However, if you turn one of the widgets, the plugin parameter will respond but the other widget will not move
Gullfoss is a plugin of a relatively recent class of plugins that dynamically equalizes audio.
It’s theory of operation is quite different from the other dynamic EQ plugins that target excessive resonance, like Soothe2 and Curves EQ. It finds pairs of frequencies where one masks the other and, controlled by user settings, boosts the masked one or attenuates the masking one. The bias control changes the balance between boosting or attenuation. The brightness control biases its operation to boost or attenuate the higher frequency one. See this post by the developer Andreas Tell (atell), or read their manual.
He wrote elsewhere that Gullfoss analyzes the signal in 40ms chunks and updates the equalization curve 25 times per second. (Sorry, can’t find the original reference for this.) This processing cycle reminds me of how mp3 encoders work – 25 chunks per second – except they do the opposite. Instead of enhancing masked signals, they’re discarded and not encoded to save bits/bandwidth in the compressed file.
OK. Having two widgets for the same parameter in one panel is probably a mistake and seeing them go out of sync might be a good thing.
But having two widgets in different panels, spaced far apart in a rack? Like having a “summary” panel for overall control followed by “detail” panels for specific functions. For example, having bypass controls for each detail panel in the summary panel as well. These will go out of sync.
The pub/sub pattern is a good method to handle this. I like TinyMessenger, about 700 lines of c# code. It’s not good for hundreds of thousands of transactions per second, but certainly ok for likely interaction rates in GP.
The designed way is this:
Add a widget
Map it to the plugin parameter
Add another widget
Do not map that widget
Link the 2 widgets via the same Widget Link
This is in the Widget Properties section General
Panels are solely UI items for visual clarity - there is no semantic meaning to an individual panel. Regardless of the panel on which a widget is placed, widgets are semantically tied to rackspaces, not panels.
Then link the widgets in your “summary panel” to the actual widgets in the “detail” panel