Implement meta parameter name changes.

[elanhickler]

Users are going to hate me.

I might be able to implement changing metaparameter names myself. Jim says I just need to call

plugin->updateHostDisplay();

The only thing I need to know from you, is how the "Meta ##" name is given in the first place, or how to change it. So I change it and then I call that update function.

found it.

[RobinSchmidt]

...i guess, the problem is that the array of metaparams is defined in jura::AudioPlugin and you don't know how to access it from your AudioModule subclass? i think you can inquire the meta-manager by

AudioModule::getMetaParameterManager

and then call

MetaParameterManager::setMetaName(int index, const String& newName);

on the returned pointer. (beware that this will be a nullptr until you have assigned it - but i think, this is done by the framework anyway...yeah...seems so)

[elanhickler]

Is there a callback or notification I can use or override to make the changes?

Also, is there a difference between setting MetaName (name used in the right click menu of slider in plugin GUI) and setting the name reported to the VST host?

[RobinSchmidt]

no there is no difference. this MetaName is the name reported to the host

[RobinSchmidt]

callback? what kind of callback would you expect?

[RobinSchmidt]

is there a difference between setting MetaName (name used in the right click menu of slider in plugin GUI)

...or...wait...what right-click menu? i see only "Enter Value", "Meta attach", "Meta detach" and "Modulation Setup" in this menu (in my chainer, with the ladder) - setName? is this something specific to your framework which i don't use myself? ..but no - i don't see it in mushroom either

[RobinSchmidt]

ah - ok - you are talking about setting it from code, not the gui, right?

[elanhickler]

Meta paramer names start out as "Meta #" in the GUI in the right-click menu when you do "meta attach". They also appear that way to the plugin host. We need to change both. When meta attachment changes we need to update the name. So we need an update callback or something.

[RobinSchmidt]

hmm...ok, i think i could make a class MetaParameterObserver or something. or maybe i just do the renaming myself in the framework when the attachment is changed. that would be simplest. but then we would need to agree on some convention, how the metas should be named

[elanhickler]

we don't need to agree, anything is better than "meta 01"!

I'll override your methods if I have to in the future.

either meta01 becomes "Amplitude" and then becomes "Ampltide+" or keep a list of connected parameters and output a final string "Amplitude,Frequency". There's not many options it seems. You could even forgo the '+' part.

[RobinSchmidt]

this list is already there anyway. the meta must keep track of its dependents, for obvious reasons. ...but there should probably be some limit on the string length

[elanhickler]

ok, then my vote is.. "Amplitude,Frequ" don't waste space with '...'

[RobinSchmidt]

ok, i have something in place to change the meta name - but, the host is not updated. i need to implement some kind of callback mechanism in order to call plugin->updateHostDisplay(); as you said above. ...probably some "MetaParameterManagerObserver"-based structure

[elanhickler]

weird new bug: assigning sliders to metaparameters no longer works off the bat. If you assign two sliders to the same metaparameter, they don't move together when moving slider with mouse.. If you control the metaparameters with host automation, then they DO start moving together. After that, they move together if you control the slider with your mouse.

[elanhickler]

HAHA! Re-loading the plugin solves this issue as well.

[RobinSchmidt]

hmm...so is the issue solved then (an the other one, too)? i just tried to assign "ClipLevel" and "Gain" to Meta 1 - and the sliders do move in sync.

[elanhickler]

No, because the plugin has to be-reloaded. It's an update problem. see gif: https://puu.sh/y8oSe/f27ea44a2b.gif