Parameter name length (the 8-char limit)

[Mayae]

Is this still a thing for VST 2.4 hosts? Has anyone ever experienced any trouble increasing this amount? I see that JUCE internally limits it to 16 chars; although the original spec clearly says 8 is the maximum.

Does any similar limit exist for other targets (VST3, AU, .. whatever?). If anyone would have mass-tested this across platforms and setups, I was thinking they might roam around here.

[camsr]

Is this still a thing for VST 2.4 hosts? Has anyone ever experienced any trouble increasing this amount? I see that JUCE internally limits it to 16 chars; although the original spec clearly says 8 is the maximum.

It's an imposed limitation (8 chars) for compatibility I think. There are places inside a DAW that you will see the parameter name in it's raw form, it just does not apply to the plugin GUI.

[Mayae]

Yes, it's specifically the latter case I'm interested in.

[camsr]

I just noticed, in FL studio, that parameter names of some plugins are more than 8 characters. It it surely a host limitation, and maybe a possible source of errors for a less diligently written host.

[aciddose]

There is absolutely no reason every host could not use a number like 4096 for the length of the buffers used to copy strings.

Ultimately though this is a fault in the design of the interface. Instead, "get string" should either return a pointer or be passed a length and return the full length of the string written.

The host/plug-in could then call such a function like this: (length passed in third dispatch function parameter)

Code: Select all

string_buffer.allocate(plugin.can_do("string length") > 0 ? plugin.get_parameter_name(index, null, 0) : 4096);
plugin.get_parameter_name(index, string_buffer, string_buffer.get_length());

Or alternatively the hurtin' old-school C way:

Code: Select all

char string_buffer[8];
plugin.get_parameter_name(index, string_buffer, sizeof(string_buffer));

The way the dispatch function / opcode are set up this already works. All we need to do is start using it.

For older VST plug-ins the response to can_do("string length") would be -1 and the third integer parameter would be automatically ignored.

Due to the way VST actually works right now (and it has been completely abandoned) the only safe way is to limit these strings to 8 characters.

"Flt Cut"

I suppose on the bright side you don't need to struggle to choose between "Amplitude" and "Volume" because only one can actually fit.

[camsr]

The way the dispatch function / opcode are set up this already works. All we need to do is start using it.

I like your code, it is backwards compatible (with minor changes to your example).

I think more than 8 is needed sometimes... sometimes I kid myself and say that everything a plugin needs to convey via parameters can fit within 8 chars if you're a geek.

[aciddose]

I thought it was backward compatible as-is. Did you notice an error?

If you mean the function names that depends upon the wrapper used by the host. I used the same names my host uses although every host will be different.

[Mayae]

Due to the way VST actually works right now (and it has been completely abandoned) the only safe way is to limit these strings to 8 characters.

"Flt Cut"

I suppose on the bright side you don't need to struggle to choose between "Amplitude" and "Volume" because only one can actually fit.

Yea it's all fun and games for simple synthesizers, but when you want to uniquely identify exported named transform matrices in nested views....

[View][Name][Type][Nested property N...] = VTSFRotZ
The Z parameter of the rotation of the transform matrix of some view

The proposed idea looks fine, but then again we need to support two naming schemes then

[aciddose]

No, not really. For the older hosts you just need to limit the length you copy to 8 chars or whatever length is specified.

When the length returned by the function (total) does not match the length provided by the host, the host can be aware of this.

You'd internally handle the situation like this:

Code: Select all

int get_parameter_name(int index, char *host_buffer, int length)
{
	my_own_buffer.allocate(4096);

	sprintf(my_own_buffer, "blah blah blah", ...);

	if (host_buffer) {
		if (length > 0) {
			strncpy(host_buffer, my_own_buffer, length);
			host_buffer[length - 1] = 0;
		} else {
			strncpy(host_buffer, my_own_buffer, 8);
			host_buffer[8 - 1] = 0;
		}
	}
	
	return strlen(my_own_buffer) + 1;
}

This is really important for UTF-8 support. You can't even do German in VST plug-ins because of this retarded limit. (The 1980s "extended ASCII" could be used with code-page specified.)

edit: added null check for host_buffer pointer.

[camsr]

About the size.. do remember that parameter names are separate of what is displayed on the GUI. If they are too big, by necessity, then wouldn't the same problem result somewhere?

aciddose, I don't have the vstsdk in front of me right now, but is your code depending on a missing function argument (length) to establish compatibility?

[aciddose]

There is no "missing" argument because this is wrapper code. It isn't part of the interface.

On the interface side you have:

int dispatch(opcode, int1, int2, void *ptr, float)

For opcode 8 (get parameter name) you have:
opcode = 8
int1 = parameter index
int2 = 0
ptr = host buffer
float = 0
returns: 0

I propose passing the length in the second integer parameter and returning the total length of the string.

[camsr]

That's what I meant
Although with function pointers, calls can be made with less parameters than defined in some circumstances, but it is poor form.

[madah]

Reaper supports this by responding to effCanDo "hasCockosExtensions" with 0xbeef0000:

Longer labels: effGetParamName/effGetParamLabel/effGetParamDisplay all support up to 256 character strings (255+null).

REAPER | Extensions to VST SDK:
http://www.reaper.fm/sdk/vst/vst_ext.php


Then you can do something like this:

Code: Select all

void getParameterName(VstInt32 index, char* label)
{
    const char* shortName = "O0fdbksr";
    const char* longName  = "Osc0 Feedback Source";

    if (hasCockosExtensions) {
        vst_strncpy(label, longName, 255);
    } else {
        vst_strncpy(label, shortName, kVstMaxParamStrLen);
    }
}

Maybe FL Studio has something similar? But be careful, never write more than the 8 char limit, since you might be overwriting and corrupting the host's memory.

[aciddose]

Host specific solutions are pointless. I'd rather just write into the host's memory and the host can crash if it doesn't support longer buffers.

The VST specification will likely never be updated so we're either stuck creating our own correct solution (as I suggest) or we need to all agree on longer length buffers such as 4096 or 256 with no way to be certain the host supports such a buffer length.

We could also create a new opcode "get max buffer length" = returns 0 for unsupported or max_length for supported.

These are lazy work-arounds and the proper solution is to pass the buffer length to the function (as in strncpy) and return the length of the string that was truncated.

Conditional string lengths could be handled by using a different source (short name vs. long name) if the buffer length is less than the minimum required although eight characters simply isn't enough for proper parameter names in the hugely complex modern plug-in.

Another thing VST needs is parameter groups. For example you might have "oscillator 1" "waveform" rather than "oscillator 1 waveform".

At eight characters we're stuck with unreadable crap like "osc1wave"

[Aleksey Vaneev]

In a "better world" the parameter names should be a list of variants of varying length:
C1Enabl1;C1 Enable 1;Comp1 Enable 1;Compressor 1 Enable Grp1
The host can choose the most appropriate variant.
And of course absolutely all strings should be in UTF-8 as the most flexible (and usually the most compact) format.

Indeed, 2-level parameter grouping would be useful as well. Without much complexity - just on the naming level like a simple parameter group name - all parameters with the same group name are displayed together. Some newer specs like AudioUnit 3 offer "parameter trees", but I think this is ridiculously complex approach and it allows plugin developers to create unusably complex trees.