Site navigation

Eight character parameter names

Audio Plugins
#1

Parameter names only come up as 8 characters - in juce_VstWrapper.cpp getParameterName it’s explicitly set to 8. Is this necessary?

I have 3 bands on my current project, and a bunch of parameters.  Not good math.  I'm getting DOS flashbacks.

I'm setting it to 24, if my computer can count that high.
#2

i think that is from initial vst1.0 specs. for full vst compatibility i think you should leave 8, but maybe i’m wrong…

#3

It’s been the longest time since I last stuck my nose in the vst spec, but wasn’t there both a short and long name field?

#4

Yes, I think some hosts might crash if you use longer strings, so I made it 8 for safety. Annoying, I know, but it’s the fault of VST spec for hard-coding stuff like this.

#5

Mmmm, hard code! No wonder I stopped programming for a decade…

Maybe I’ll do some testing with long names on different apps and os’es and let you know.

#6

the VST 2.4 confirms the 8 character limit. and encourage people to use vst_strncpy() to enure this, see below.

[code]
enum
{
//-------------------------------------------------------------------------------------------------------
kVstMaxProgNameLen = 24, ///< used for #effGetProgramName, #effSetProgramName, #effGetProgramNameIndexed
kVstMaxParamStrLen = 8, ///< used for #effGetParamLabel, #effGetParamDisplay, #effGetParamName
kVstMaxVendorStrLen = 64, ///< used for #effGetVendorString, #audioMasterGetVendorString
kVstMaxProductStrLen = 64, ///< used for #effGetProductString, #audioMasterGetProductString
kVstMaxEffectNameLen = 32 ///< used for #effGetEffectName
//-------------------------------------------------------------------------------------------------------
};

//-------------------------------------------------------------------------------------------------------
/** String copy taking care of null terminator. /
//-------------------------------------------------------------------------------------------------------
inline char vst_strncpy (char* dst, const char* src, size_t maxLen)
{
char* result = strncpy (dst, src, maxLen);
dst[maxLen] = 0;
return result;
}[/code]

you might overcome limitation by using the VstParameterProperties structure, but I doubt many host really use it. There are so many plugin out there that don’t implement it.

enum Vst2StringConstants
{
//-------------------------------------------------------------------------------------------------------
	kVstMaxNameLen       = 64,	///< used for #MidiProgramName, #MidiProgramCategory, #MidiKeyName, #VstSpeakerProperties, #VstPinProperties
	kVstMaxLabelLen      = 64,	///< used for #VstParameterProperties->label, #VstPinProperties->label
	kVstMaxShortLabelLen = 8,	///< used for #VstParameterProperties->shortLabel, #VstPinProperties->shortLabel
	kVstMaxCategLabelLen = 24,	///< used for #VstParameterProperties->label
	kVstMaxFileNameLen   = 100	///< used for #VstAudioFile->name
//-------------------------------------------------------------------------------------------------------
};
#7

you may want to support vstxml, i think more people will support it soon.

#8

Well I tried more characters; showed garbage names in one host, OK in another, will buy a 3rd cheapie (Cubase SE) tomorrow, but 1 out of 2 isn’t cool.

I was just trying automation, and other plugins got longer names though those plugins are specific to Sonar.

I have little interest in supporting ancient hosts, but if it sounds fine and looks bad then longer names aren’t worth it, and detecting whether the host supports it could just be a major league hack.

At this point my main project handles parameter changes well enough internally, based on RMS, which I firmly believe every plugin should do - it sounds so much better if some parameters are tweaked based on RMS, which juce makes way too easy with AudioSampleBuffer::getRMSLevel(). Distortion threshold, mix level, feedback, whatever - it’s so much less digital sounding with a bit of controlled volatility…

me.havingFunWithThis() == true;

Dave Heinemann

#9

yeah, vstxml is undoubtedly going to be a big deal pretty soon.

#10

I’ve not looked at vstxml yet, I guess I’ll have to eventually…

#11

the new VstWrapper needs to include the enum for the max string length when using vst sdk 2.3

#if JUCE_USE_VSTSDK_2_4 // VSTSDK V2.4 includes.. #include "public.sdk/source/vst2.x/audioeffectx.h" #include "public.sdk/source/vst2.x/aeffeditor.h" #include "public.sdk/source/vst2.x/audioeffectx.cpp" #include "public.sdk/source/vst2.x/audioeffect.cpp" #else // VSTSDK V2.3 includes.. #include "source/common/audioeffectx.h" #include "source/common/AEffEditor.hpp" #include "source/common/audioeffectx.cpp" #include "source/common/AudioEffect.cpp" typedef long VstInt32; typedef long VstIntPtr; enum Vst2StringConstants { kVstMaxNameLen = 64, kVstMaxLabelLen = 64, kVstMaxShortLabelLen = 8, kVstMaxCategLabelLen = 24, kVstMaxFileNameLen = 100 }; #endif

since you are using it in JuceVSTWrapper::getOutputProperties/getInputProperties…

#12

Cheers Kraken, I’ve only been using 2.4 lately.

#13