AudioProcessorValueTreeState parameter name change?

I’ve trawled this forum end to end and I can’t find an example of someone successfully changing the name of a parameter when using AudioProcessorValueTreeState.

(Which is comforting, because it makes me feel like perhaps I’m not missing something obvious.)

So, am I missing something obvious? I see that the public variable “name” is a const, which implies… what?

Halp?

Further to that, it would be very nice to have a setName() for the parameters that rolled the appropriate refresh automagically.

I don’t think Juce supports making any changes to the properties of the parameters or the number of parameters after they’ve been created and added into the AudioProcessor. IIRC the reasoning has been that support for those things isn’t universally available in hosts. So even if you managed to change for example the name of a parameter dynamically on the Juce side, there might not necessarily be any universal way to force the host to change the used name too. For example the host might just look through the parameter names once when the plugin is loaded and it might not bother scanning them again later.

Yeah, I’ve seen them mention that before. But that’s a shitty reason. There are dozens of format features that aren’t recognized by all hosts; I don’t see why this one is particular. The Big Five all recognize it.

1 Like

Which are the big 5? On all different plug-in formats? What should the fallback behaviour be if a parameter’s name can’t be changed?

Logic, Live, Cubase, PT, and FL. And AU, AAX, and VST3 all have methods for it. Since VST is being deprecated anyhow, I propose to deal with it the same way we deal with Sidechain inputs. If the host doesn’t have it, tough luck. This would put the onus on hosts to have it.

I’m pondering a fallback. I just woke up, so the caffeine has not had a chance to bring all my neurons on line. Gimme a minute.

My 2 cents.
While you can’t have any runtime changes regarding number of parameters.
Parameter name changes works fine. We use it (not using juce framework though)
and Native Instrument Kontakt relies on it too.

Yeah, changing the number or ranges of existing parameters is a much bigger task, but perhaps we can get name changes in without butchering the API too badly.

Call me old fashioned, but changing the number of params is on the List Of Things Thou Shalt Not Do. That is disaster territory. But (assuming there’s a default name to deal with the hosts that can’t take it) it seems adding parameter name change as a method is a fairly simple process.

I wonder, what is the binding identification anyway?
Do the parameter IDs find their way to the host at all?
Or is it internally still indexed?
I always thought the parameter name is a pure display information anyway?

My understanding is that the name is sent to the host (and followed by a refresh-all-parameters command if it happens after the instance) but it is mainly an internal thing as far as the plug is concerned.

e.g. just take that const out from in front of the name variable, and the name is persistent internally. However, it isn’t actually stored in the value tree, at least the parts that get thrown to the blob. If you look at the XML output of the tree, all you get is the ID string and the value. So one would need to store it in the state and update when the state is reloaded manually.

tl;dr: the host doesn’t give a shit. The enum is the thing. It’s really just a matter of getting the host to update.

Yes, and same goes for the XML… in the end it’s automation values, that get sent.
The XML is just for the plugin developer, for things, that need no automation, and in case the host doesn’t automate by default.

I am just curious/confused about the paramID from a hosts perspective, it seems to me like it isn’t even exposed…