Audio Units / VST parameters in hosts - units, range, resolution

So it seems like quite a few people have touched on this, but I've been unable to find anything that approaches an all-encompassing solution.

What is the best way to set up plugin parameter properties? Audio Units and VST3 plugins can display a unit (i.e. Hz, dB, cents), have a mimum and maximum range, and a resolution (1's, 0.1's, etc) in a host. 

JUCE plugins seem to default to map every parameter from 0 to 1, which is really inadequate for modifying real-world parameters (like gains in dB, pans from -100 to +100, pitches in cents, etc..). I've been able to figure out how to set up some parameter ranges by modifying AudioProcessor.h and AudioProcessor.cpp as well as juce_AU_Wrapper.mm as outlined by dave96 here: 

http://www.juce.com/forum/topic/improvements-handle-au-parameter-ranges

Howver I'm running into a few bugs with these methods, not to mention I'm unable to yet display units and set a resolution in the host,  and I'm not at all excited about having to dive into making changes to the JUCE modules to get this behavior working properly.  Does anyone have a comprehensive solution for displaying parameters properly in the host?

 

"VST3 plugins can ... have a mimum and maximum range"

At least according to Steinberg's API documentation, that is not true. The parameter values must be passed from and to the host normalized within [0.0 , 1.0]. It's only the methods provided for passing string representations of that parameter from and to the host that enable the host to display non-normalized parameters (and those are not fully supported by JUCE).

Hence, modifications similar to what is suggested for AU are not possible for VST3. I found it more promising to stick to [0.0 , 1.0] for all platforms and rather try to improve the support for passing string representations of the parameters. There are methods dealing with parameter-to-string- and string-to-parameter-conversion in both AU (getProperty/getPropertyInfo for properties kAudioUnitProperty_ParameterStringFromValue, kAudioUnitProperty_ParameterValueFromString) and VST3 (getParamStringByValue, getParamValueByString) that are not supported by JUCE.
I tried to add support for them by mapping them to new AudioProcessor-methods (getParameterTextByValue, getParameterByText) that must be overriden to do that conversion - see here for the changes I did: https://github.com/MartinHH/JUCE/compare/developMH#files_bucket.
My solution is far from comprehensive, but I wanted to point out an alternative approach to achieve better displaying of parameters. One problem is that not all AU hosts use those getters. They work fine with Apple hosts, but for example, Ardour will still display the normalized values.

 

P.S.: afaik, the VST3 wrapper correctly supports setting the resolution (of the normalized values) if you correctly override getParameterNumSteps (however, the AU wrapper apparently does not call getParameterNumSteps at all).

Hey guys,

Thanks so much for the reccomendations. I've been playing around with both of your code for the last few days and have begun to figure out how to make it all work for me - I'm pretty sure that I'm going to normalize all parameters to [0.0, 1.0] and set up a parameter class that can scale those values appropriately for each parameter, sending the scaled values to any labels in the GUI and to the host with something akin to getParameterTextByValue suggested by Mart.

In the end sticking to normalised 0-1.0 is very handy - just scale it to where you need on the display.

Caveat is that Ableton currently still likes to display the normalised range - so ....pick yer poison.

I posted a similar question yesterday on this subject, before running into this thread. Cubase and Nuendo not only need to display the denormalized (raw) values but also allow the user to enter new values via a text unput and/or slider, directly in the host. I found some methods in the VST wrapper whic allow the host to call user-defined conversion functions but they don't appear to be accessible in the public APIs.

Here's my post which shows the methods in question.

http://www.juce.com/forum/topic/problem-editing-automation-points-cubase/nuendo

For automation to work correctly in Cubase/Nuendo, these functions need to be accessible.

 

 

Text <-> value conversion support is now in the latest tip. This effectively fixes editing of automation points in Cubase/Nuendo as the host requires support for converting automation point values to text and then back again. You need to use AudioProcessorParameter to make use of this feature (see, for example, the updated audio plugin demo). Proper units and range support is on our roadmap.

Thanks! I got those changes and they work perfectly.

 

Hello, I just updated my VST plug-in to use AudioProcessorParameters. You mentioned in the previous message that Units and Range support will be available some time in the future, and I am wondering when that might be. This was the reason I updated, to allow for automation parity across all DAWs smiley

Is there anything that we can experiment with or work-around in this class that may give us the ability to set the range values so that we can automate properly? I don't mind that Ableton shows it's values from 0->1; provided I can set ranges in Juce and all sliders and labels render properly I am happy.

Also, is it possible to turn off processor parameters from being exposed immediately within the DAW (I am currently using Ableton). I have seen many plug-ins have their parameters hidden unless you decide you want to expose them.

Many thanks,
Peter

I don't think that the plugins hide parameters in ableton. It's more a feature of ableton. They hide parameters automatically if you have a lot.

I did not realize that (just checked to confirm). Thanks for clarifying Patrick!

Any chance of allowing us to set the proper kAudioUnitParameterUnit in the future as well? AFAIK, this would allow snapping for indexed parameter automation in AU hosts (though it would also require using non-0-to-1 values for the host).

1 Like