Set Parameter Value Without Notifying Host

Hey there,

I am building an audio plugin which allows to save custom presets and then offers a parameter to automate between those presets. So far this is working fine.

However, there are some problems with automation recording in some hosts: Each custom preset is a set of values for the underlying low-level parameters of the plugin. When a preset is being loaded all these low-level parameters are being set by calling getParameterAsValue() and then assigning the new value to the parameter. This parameter change seems to cause problem since the host is being notified about it and tries to store this parameter change is automation.

Consequently, each time there is a switch between presets, the host gets lots of notifications and automation data which is undesired.

Is there a way to set the parameter values of the ValueTree without notifying the host?

A simple solution would be to set the lowlevel parameters to be non-automatable. But this is not ideal because in some scenarios users would maybe also want to automate them.

The issues have been reported mostly by ProTools users so far.

Has anybody an idea how to solve this?

I think it is not desirable to have an inconsistent state between the values in the host and the value your plugin sets. What would you expect the value to be if the user quits and reopens?

I think the value changes from the preset change should definitely end up in the host.

I don’t think there is a way to shift the responsibility for the value (single source of truth) between the plugin and the host. Either it’s automatable and the host is in charge or it is not automatable and the plugin can to what it sees fit.

As @daniel said, you definitely want the host to get a notification for each parameter, otherwise it would end up being out of sync (many hosts provide their own simplified UI to control plugins).

This all comes down to a design question: what parameters should you make automatable? It seems that you want all of them to be, just in case the user wants to tweak some low level stuff, but that’s the drawback of such design. You could either reduce the number of exposed parameters, or make macros instead of exposing them individually.

Thanks for your answers!

Sure, the parameters should stay in sync all the time. However, I a thought there might be a way to set the value of the parameter which makes it clear to the host that this parameter change is no new automation data to record.

For now, my solution is to make isAutomatable() false for the low-level parameters. As already said this is not ideal but okay for now.

Another thing I tried is to offer the possibility to switch between two automation modes: preset automation and individual parameter automation. I tried to programmatically change the value returned by isAutomatable() to true when the user selects individual parameter automation mode. Unfortunately, most hosts don’t seem to update their parameter list even after calling updateHostDisplay()

Indeed hosts will query isAutomatable on plugin creation to create their own internal parameter list. So changing this value dynamically is not how the framework is supposed to work and will be ignored.

Again, saying that “making low level parameters non automatable is not ideal” is a wrong statement in my opinion. You should see the “automatable” flag as a way to expose parameters to the user. “Low-level” parameters should therefore not be automatable, since they should not be exposed to the user. This is a design problem.

Regarding a way to send parameter changes without them being recorded as an automation, this is indeed impossible but I’m not sure I understand the issue: if the host is not playing and not recording anything, the changes should not end up creating automation points. The host should only record parameter changes as automation when it is actually recording automations.

1 Like

We’ve had a similar issue for years, where we automate a couple of parameters that in turn modify several other automatable parameters. The old VST docs used to say that was something you should avoid doing, and I’ve argued against it, but everyone seems to want them all automatable. To me, it would be better to not automate the “meta” parameter, and to instead automate only the parameters that it affects, because those are the “real” parameters, and the ones users would be most interested in automating individually. I’d even suggest making the meta-parameter not a parameter at all, personally.

Say you have parameter X in a drop-down, with values A, B and C. When set to A, parameters Y and Z should both be set to 0.0. When parameter X is set to B, parameters Y and Z should be set to 0.5. And when parameter X is set to C, parameters Y and Z should be set to 1.0. Now, the user selects B for parameter X. That sets Y and Z to 0.5. Then the user sets Y to 0.75 and Z to 0.25. But parameter X still shows B. That is inconsistent. How can X be B if Y and Z are not 0.5? What does the value of parameter X really mean? In my opinion, it should be just a kind of “trigger” to set initial values for Y and Z, not a parameter in its own right at all.

Just my opinion. Unfortunately, we programmers rarely get to make those design decisions.

4 Likes