In what context is the host using the param 'name' field

[SamWindell]

With the params extension, I wonder if we can be more specific regarding how the name field will be used by the host.

Say for example I have a parameter for controlling the starting point of a loop, and it is located on my GUI within the 'Layer 1' section, and then within a subsection called Loop.

It makes sense that I would set the module to "Layer 1/Loop".

But how precise should the name be? "Layer 1 Loop Start" or simply "Start".

I think it would depend on whether the host is displaying the name in isolation, or if it is displaying the name alongside the module. If set the long name, but the host also displays the module text next to it, then that's a lot of duplicated text shown to the user.

Anyone have any thoughts on this?

[robbert-vdh]

I'd assume the host only shows the name and go for 'Layer 1 Loop Start'. Parameter modules are mostly there for organization, and most hosts don't even use them.

[defiantnerd]

The name should not repeat the module string. if module is Layer 1/Loop, the name should be Start. Otherwise, you will get displays like Layer 1/Loop/Layer 1 Loop Start.

I would consider hosts not displaying the module string broken.

[robbert-vdh]

Then all hosts except for the CLAP test host (which displays the parameters in a tree) are broken.

[baconpaul]

Your definition means bitwig and reaper and logic are broken alas.

The unfortunate truth is that hosts don't reliably use the AU group, VST3 group or (yet) CLAP modules - and VST2 doesn't have groups at all. We have a similar problem in surge where the Scene A oscillators have param names which may or may not include the group names so choose names like this

    {
                     "flags" : [ "auto", "mod", "mod-noteid", "mod-key", "mod-channel", "mod-port" ],
                     "id" : "0x2564a236",
                     "module" : "/A Oscillators/",
                     "name" : "A Osc 1 High Cut",
                     "values" : {
                        "current" : 1.0,
                        "default" : 0.0,
                        "max" : 1.0,
                        "min" : 0.0
                     }
                  },

which could be /Scene A/Oscillator 1/High Cut in clap but then would render in bitwig as High Cut in their preview

In some cases, REAPER even displays a flat list of all your params without groups. Here's the Surge XT VST3 in a fairly recent reaper build.

So I think, defacto, you need to have "Layer 1/Loop/Layer 1 Loop Start" if you are deploying to the hosts we have today, even though that answer bums me out a bit.

[tim-janik]

I'd assume the host only shows the name and go for 'Layer 1 Loop Start'. Parameter modules are mostly there for organization, and most hosts don't even use them.

Anklang has parameter groups and maps CLAP param modules to them. It shows group names in the UI and actually forms real UI groups from them. Here is a snapshot from parts of the Anklang device panel UI for Surge. Note that it uses auto-abbreviated parameter names, hovering shows the actual parameter name.

However, because Surge has so many parameters and thus the groups are so large, it also splits the groups into "pages".

[urshimself]

I'm with Timo. We reluctantly coded an exception in our CLAP support where we prefix our params with the module name, because hosts are currently disregarding the module names.

Logic btw. shows AU Clump names just fine, at least in the drop down menus.

[baconpaul]

yeah but not in the automation lanes right?

[baconpaul]

yup. The automation lane just shows the leaf name

even though the selection menu if you create a lane uses the tree

[defiantnerd]

This pattern works fine with AU in Logic and with VST3 in Cubase, Studio One etc.
The wrapper (which is a kind of host by itself) uses the module string to build the hierarchical unit structure so Cubase runs the parameters properly:

and the comment in the parameter extension is quite clear about it:

https://github.com/free-audio/clap/blob/main/include/clap/ext/params.h#L227

   // the display name
   char name[CLAP_NAME_SIZE];

   // the module path containing the param, eg:"oscillators/wt1"
   // '/' will be used as a separator to show a tree like structure.
   char module[CLAP_PATH_SIZE];

by repeating (probably not even byte equal) the path in the parameter name you would prevent any proper use of such a structure.

I would strongly urge hosts to fix that behavior as soon as possible.

[baconpaul]

Here's what LIVE does with the surge xt vst3. It basically ignores the VST3 groups

Here's a bitwig device with the Surge XT VST3.

(I don't even know where the module would go in that UI actually).

So while I agree with you timo and urs, that full hierarchical view of parameters would be amazing, I think the reality of shipping a plugin today - independent of CLAP or not - is that if you rely on the module name being an integral part of the display your users won't see it reliably.

[defiantnerd]

A bit disappointing that this is not fixed in Live since more than 10 years.

[baconpaul]

i thought VST3 support in live was only 4 or 5 years old?

But yes the variety of approaches to this across the DAWs makes it very tricky indeed when trying to figure out how to set up a parameter set for a synth, alas.

[Bremmers]

Perhaps you should expect the module name to be used for menus only. If at all.

module + name is often (much) too long for an automation lane name. I think most host developers tried adding the module name, and removed it again after seeing 'Oscillator 1 - Osc 1 Frequency'.

[baconpaul]

Whether that's what we should expect I agree it is basically what we get in almost all DAWs today; that means alas people will make choices like we did in surge; which means DAWs which change their mind will get a lot of A/Osc/Foo/A Osc Foo

[defiantnerd]

This is a thing for tooltips and stuff.

In the VST2 days we had simply automation for the mod matrix sources, which had it‘s own appeal.

[SamWindell]

Thanks, lots of good information here. For now, it seems like its probably best to put the full long name in the name field, even though it's far from ideal.

I don't know what the backwards compatibility considerations are, but can we change the API?

Maybe something like this:

   // The full display name (ideally unique). The host can display this to the user with no other context. 
   // e.g. 'Osc Wavetable 1 Position'
   char name[CLAP_NAME_SIZE];

   // The name of the parameter in a path-like format. This can be used to display the parameter in a 
   // tree-like structure. Similarly a filesystem path, '/' should be used as the separator. The last component 
   // of the path is name of the parameter: this can be brief, because it will always be shown alongside 
   // the preceding 'folders'.
   // e.g. 'Oscillators/Wavetable 1/Position' where the parameter is called Position within the sections 
   // Oscillators and Wavetable 1.
   char pathname[CLAP_PATH_SIZE];

[defiantnerd]

I totally agree. The host should not so guess work, same for the plugin that should not compensate short-comings of hosts.

name is the name, module is the path and name shall not duplicate the module partially.

Right now, when host developers are probably start implementing CLAP, this should be clearly defined.

Otherwise we are getting back into that messy VST2 world where a feature matrix was matched against host name and version…

[SamWindell]

That's fine, I'm on board with this idea too.

I suspect some addition documentation in the header might be in order to encourage plugin and host devs to adopt the rules you've suggested.

[tim-janik]

That's fine, I'm on board with this idea too.

I suspect some addition documentation in the header might be in order to encourage plugin and host devs to adopt the rules you've suggested.

Yeah, recommendations could certainly help.
Care to cook up a PR that implements this?

[SamWindell]

Yep I can make a PR

[SamWindell]

Here it is: #263