AudioParameter Renaming


#1

Hello together,
I am writing a Plugin using the addParameter() feature to create a bunch of AudioParameterInt objects.
Is it possible to let the user rename them so that they appear in the DAW Automation with the new name given?

any help would be appreciated.
Thanks a lot.


ValueTree Gui-connecting example Feedback
#2

Well, yes… Obviously your code is what provides the names for the host to use, so there’s nothing stopping you asking the user for names and returning those.


#3

As long you didn’t change the position of the parameter inside the parameter-list, or the parameterID this should work, but, if the host supports such dynamically renamed parameter description (also per plug-in instance), i would say, probably NOT.
(Also there is no way to signal the host, that parameter descriptions have changed)


#4

This is usually the purpose of AudioProcessor::updateHostDisplay().
But a) the AudioProcessorParameter has a getter, but no setter for the name, so it can only be set at creation and b) the wrappers have to implement that (haven’t checked, but I doubt that).

So at runtime I agree with @chkn it’s probably not possible, but if you want it renamed at the next instanciation, that would be possible, but I don’t find that particularly useful…


#5

We do this at runtime and astonishingly, it works quite well in most hosts. I don’t remember which ones, but only a few won’t update the name at all.

There are edge cases for example in Reaper where the name in an automation lane doesn’t update while the parameter list names are shown correctly after a change.


#6

Wow, I am surprised. Did you patch AudioProcessorParameter then to have a setName() ? Or was I just blind not to see that setter?


#7

It’s a bit more complicated; we use a parameter holder class which can reference to another internally used parameter. In the end it should suffice to add some setParameterName() which sets a string that is then returned by getName().

I think we also had to patch the AU wrapper (optional PropertyChanged (kAudioUnitProperty_ParameterList, kAudioUnitScope_Global, 0)) and maybe others a little to get the host to notice but in the end it was unexpectedly smooth.


#8

That’s what I thought, because I was staring at that method last week (because there is also stuff that needs to be different for FCPX - OT), and I didn’t see the name properties…


#9

Thank you for your replies.
I think I did not quite get the concept of the Parameter Classes.
When I want to get to a Parameter Object I use

getParameters()->getUnchecked(index)

What that should give me (I think) is a previously added Object of AudioParameterInt. I added a dynamicName String, a setName() to chance the dynamicName and altered the getName() to return the dynamicName.

The problem is that I cannot access the setName() function when I add it to the AudioProcessorParameterWithID class although the AudioParameterInt Object should derive from the AudioProcessorParameterWithID class or should it not?

Instead the getParameters() gives me the Object as an AudioProcessorParameter, so no setName() function available.

I am not a pro and my programming skills lack detail and some understanding, so bear with me :slight_smile:

edit:
oh and yes, I want the user to be able to change names during runtime of the plugin.
If it is to complicated then so be it. I might come back later to that problem in a year or so :wink:


#10

I mean… is it that complicated?
I am always willing to learn


#11

Unfortunately yes, because in the audio plugin space you’re often fighting to figure out host-specific behavior which may not be defined or be defined differently in different plugin hosts or hosting standards, especially when dealing with stuff you want the host to be responsible for (i.e. plugin parameter display).

In my own past experience where I wanted to do something similar, I found @chkn’s response to be closest to my own experience - don’t mess with the parameter indices, and there’s a chance the host may not update the names even after asking it to do so.