CONTROL OF VST PLUG-INS USING OSC

Michael Zbyszyński Adrian Freed

Center for New Music and Audio Technologies (CNMAT)
Department of Music
University of California, Berkeley
1750 Arch Street
Berkeley, CA, USA
{mzed, adrian}@[Link]

ABSTRACT from the particular plug-in, allowing composers to adapt

and repurpose pieces as plug-ins evolve.
The basic control structure of VST audio plug-ins can
limit their usefulness. Control can be improved through
the use of Open Sound Control by developing a flexible 2. Problems with VST Control Structure
name space that employs multiple, intuitive parameter
names (and aliases), higher-level controls and range
mapping, simplifying control for the user. We will 2.1. Names Dictated by Plug-In Designers
demonstrate these ideas with Max/MSP patches that
repackage VST plug-ins in a more usable way and also
introduce the idea that plug-in interfaces themselves can 2.1.1. More intuitive names
be improved by building in a well-formed OSC name
space. Such a name space would enhance the longevity Many audio processing plug-ins fall into typical
and flexibility of finished musical works. We will also categories, such as dynamics processors or reverbs.
show that when the plug-in is controlled directly with Each specific user has expectations for the names of the
OSC atomicity and queries, control could be further parameters in an archetypical reverb, for instance, which
improved. are determined by that user’s technical and linguistic
background. Where one user might expect a parameter
called “Wet Level,” another might be more familiar
1. INTRODUCTION with “Reverb Gain.” Users must adapt to the naming
scheme of the plug-in designer. This complicates the
While audio plug-ins are extremely useful, limitations of use of multiple plug-ins from disparate sources; in
their control structure can make them unwieldy to use. Max/MSP, for example, the user might need to
Specifically, the name space of each VST plug-in [1] is constantly change naming schemes to do something as
flat and populated by parameter names that have been simple as auditioning multiple reverbs with similar
carefully chosen by the designers of the plug-in, but do parameter settings.
not necessarily represent the terminology or language
preferred by the user. Parameter names are mapped
through a generic range (0. to 1.) without informing the 2.1.2. Possibility of aliases
user about the mapping range or the specific units that
are employed inside the plug-in, and each message The use of a rich OSC name space provides the
controls only one parameter. opportunity for multiple aliases to the same parameter.
Through the use of Open Sound Control (OSC) An intelligent naming scheme would direct both “Wet
[2], a flexible name space can be developed that Level” and “Reverb Gain” to the same parameter,
employs multiple, intuitive parameter names (and allowing the user to focus on the specifics of controlling
aliases), higher-level controls and range mapping, the sound. If the user changes reverb plug-ins, they
simplifying control for the user. We will demonstrate could continue with their preferred naming scheme for
these ideas with Max/MSP patches that repackage VST the generic parameters. They could concentrate on the
plug-ins in a more usable way and also introduce the sonic differences between reverb algorithms, rather then
idea that plug-in interfaces themselves can be improved the naming idiosyncrasies of each design. Similarly,
by building in a well-formed OSC name space. We will different users could address the same patch using the
also suggest ways (e.g., atomicity and queries) that naming scheme that is most familiar to them.
control could be further improved if the plug-in could be
controlled directly with OSC. 2.1.3. Simplified reconstruction
In addition to creating a more useable control
structure, careful use of the OSC abstractions proposed
Another advantage to a carefully designed name space
here will allow composers and performers to create
would come when documenting, preserving, or
more fully documented works than can be easily
reconstructing a finished musical work. Because the
updated with changing technologies. A thoughtfully
musician’s original sonic intent would be represented in
designed name space can separate the musical intention
a form that was not tied to a specific plug-in
technology, it could be easily understood and adapted to
suit the situation of future technologies. When a piece 2.3.3. One message, many parameters
travels or is revisited, explicitly descriptive parameter
names, such as “Reverb Gain,” are more easily Another advantage of a careful created OSC name space
interpreted than opaque names, such as “Mix” or would the use higher-level names that control multiple
Mode.” parameters. In the example the context of multi-band
compression, the user might be given explicit control of
the cut-off frequencies between the low, middle, and
2.2. Parameters mapped to a generic range
high bands. Alternatively, the user could prefer to
The next step in an intelligent plug-in control scheme control the center frequency and bandwidth of the
would be to address parameters in established units. All middle band. With OSC, these high-level parameter
VST parameters are currently mapped to the range of names could be created to adjust the appropriate
0.0 to 1.0, effectively obscuring the values being crossover frequencies accordingly.
controlled. Furthermore, a particular user might prefer
setting crossover frequencies in Hertz or MIDI cents, 3. OSC SOLUTION IN MAX/MSP
and might prefer percentages to decibels as a unit of
loudness. In addition to parameter name aliases,
parameters could be addressed in specific units. For 3.1. Two reverb example
example “Wet Level 63%” or “Reverb Gain –6dB.” By
accommodating specific user’s predilections, plug-ins
would become more intuitively useable.

2.3. Flat Name Space

2.3.1. Hierarchical name space

The naming space for VST plug-ins is flat, simply a list

of parameters that could be addressed. While this might
be adequate for plug-ins with a few parameters, some
plug-ins (e.g. Waves Parametric Convolution Reverb
[3]) can have dozens of parameters. In such a case, it
makes sense to organize parameters in a hierarchical
name space. For instance, a multiband compressor will
have many crossover frequencies. These could be
addressed as “/crossover/low<->mid n” and
“/crossover/mid<->high n” (or, depending on the user,
“/crossover/middle<->hi n” or “/x-over/m<->h n”).
Such a naming scheme would help keep the control
structure clear and comprehensible.
The ability to reorganize parameters in a clear
hierarchy would have special significance in to users
working with assistive technologies. For example, blind
users working with screen readers could customize their
name space to quickly navigate to the most pertinent
parameters, rather than waiting to read through a long
list of all possibilities.
Figure 1. Top level of two reverb patch
2.3.2. Pattern matching
The following examples were programmed in Max/MSP
A carefully designed hierarchical name space would following the name space design guidelines suggested
allow the user leverage OSC’s use of pattern matching. above. The first demonstrates a control structure for
[4] Following the example of a multiband compressor, controlling two reverb plug-ins (mda Freeverb [5] and
the compression thresholds might be named Griesinger 2.2 by Nathan Wolek [6]), each with
“/low/threshold n,” /middle/threshold n,” and different parameter names.
“/high/threshold n.” In the OSC Address Pattern, “*”
matches any sequence of zero or more characters. This This name space was designed to enable the user to
would allow the user to simultaneously adjust all switch between the reverb plug-ins while maintaining a
thresholds by sending the message “/*/threshold n.” consistent control structure. Similar parameters in each
plug-in are addressed with the same name. For instance,
“Reverblevel” addresses “Wetlevel” in the Freeverb and
“reverbgain” in the Griesinger reverb. The example
also suggests the possibility of aliases and
Specific bands:
unconventional terminology; “slimeyness” is also
/[Low, low, L, l]/[Comp, Compression, comp,
mapped to “Wetlevel” and “reverbgain.”
compression] [0.-1.]
/[Low, low, L, l]/[dbcomp, dBcomp] [0.-30.]
Freeverb: Griesinger: /[Low, low, L, l]/[Out, Output, out, output] [0.-1.]
/[Freeverb, 1]/Mode [0.- n/a /[Low, low, L, l]/[dboutput, dBoutput] [-20.- 20.]
1.] /[Mid, mid, M, m/[Comp, Compression, comp,
n/a /[Griesinger, 2]/bandwidth compression] [0.-1.]
[0.-1.] /[Mid, mid, M, m]/[Out, Output, out, output] [0.-1.]
/[Freeverb, 1]/Roomsize /[Griesinger, 2]/Roomsize /[Mid, mid, M, m/[dbcomp, dBcomp] [0.-30.]
[0.-1.] [0.-1.] /[Mid, mid, M, m]/[dboutput, dBoutput] [-20.- 20.]
/[Freeverb, 1]/Width [0.- /[Griesinger, 2]/Damping /[Hi, hi, H, high]/[Comp, Compression, comp,
1.] [0.-1.] compression] [0.-1.]
n/a /[Griesinger, 2]/pre-delay /[Hi, hi, H, high]/[Out, Output, out, output] [0.-1.]
[0.-1.] /[Hi, hi, H, high]/[dbcomp, dBcomp] [0.-30.]
/[Freeverb, 1]/Reverblevel /[Griesinger, /[Hi, hi, H, high]/[dboutput, dBoutput] [-20.- 20.]
[0.-1.] 2]/Reverblevel [0.-1.]
/[Freeverb, 1]/Drylevel /[Griesinger, 2]/Drylevel Higher-level parameters:
[0.-1.] [0.-1.] /Mid-CF [value in HZ]
/[Freeverb, 1]/slimeyness /[Griesinger, /Mid-BW [value in HZ]
[0.-1.] 2]/slimeyness [0.-1.] General Parameters:
Table 1. Name space for two reverb patch /L<>M [0.-1.]
/M<>H [0.-1.]
/LM-Hz [87.-1020.]
3.2. Multiband compressor example /MH-HZ [111.-19606.]
/Attack [0.-1.]
The namespace for controlling a multiband compressor
/Release [0.-1.]
(mda MultiBand [7]) is much more complicated,
/Stereo [0.-1.]
especially in its use of aliases. It also includes higer
/Process [0.-1.]
level parameters that influence more than one of the
plug-in’s built in parameters. Table 2. Name space for multiband compressor patch
The first group of names address single plug-in
parameters, and demonstrate multiple naming
The patch, below, also uses OSC’s pattern
possibilities for the same parameter. Different users
matching abilities. To adjust all of the output gains
might prefer “Hi” to “high,” or simply “H.” This space
simultaneously and in decibles, the user sends the
could be expanded to include other aliases for language
message: “/?/dboutput n.” Variants of this message
localization. Additionally, the parameters “/*/[dbcomp,
using other aliases are also available.
dBcomp]” and “/*/[dboutput, dBoutput]” employ real
units, decibels instead of the generic range of 0. to 1.
They are mapped accordingly in the max patch before
being sent to the plug-in. Other units of loudness or
intensity could be added, each with their own mapping.
The second pair of names are higher-level
parameters. They allow the user to directly control the
center frequency and bandwidth of the middle
compression band, implicitly influence all three bands.
The OSC parameter value is translated into the proper
crossover frequencies for both the low to middle and the
middle to high crossover, and forwarded to the plug-ins
built in parameters.
The final group of generalized parameters
includes another example of real units, setting the
crossover frequencies in Hertz.
 Figure 2. Top level of multiband compression patch by implementing a thoughtfully designed control
structure in OSC that includes:
4. SUGGESTIONS FOR FURTHER • an hierarchical name space designed to take
IMPROVEMENT advantage of pattern matching

All of the Max/MSP examples in this paper were hand • a set of naming conventions that exhibits clarity and
built around specific plug-ins. [8] It is possible to query portability
parameter names, but each plug-in had to be loaded and • flexibility in naming to accommodate users with
observed in action to determine the exact units and diverse abilities, backgrounds, and intentions
range of each parameter. Even the, the curve to which
the parameters are mapped is not always obvious. OSC • values addressable in real units
supports a full querying system. If OSC support was • high-level parameters that allow the user to control
integrated into VST plug-ins, much of this namespace multiple values or multiple plug-ins with single
could be built automatically, or built in advance by the messages
plug-in designer. Plug-in vendors have met this
suggestion with enthusiastic support. In the Open • atomicity in message handling
Sound World environment, some of this handwork Such a control structure would improve control during
would be simplified because all objects inherit a the creation of musical works, as well as simplify the
hierarchical OSC name space, including the VST plug- preservation and reconstruction of works in the future.
in loader. Products by Native Instruments [9], Reaktor
and Intakt, already support OSC in their standalone
6. ACKNOWLEDGEMENTS
applications, but it is not possible to address their plug-
ins directly using OSC. Special thanks to the UC Discovery Grant Program for
Another important feature of OSC is atomicity. its generous support.
Messages that should be executed simultaneously can be
sent together as an indivisible bundle; they will be either 7. REFERENCES
all executed in one scheduler tick, or none will be.
While this behavior is desirable in many circumstances, [1] Steinberg Media Technologies “VST Plug-ins SDK
it could be critical in cases such as updating filter 2.3.”[Link]
coefficients. Coefficients received serially could lead to k /OnlineDoc/vstsdk2.3/[Link], 4 March 2005.
an unstable filter state. Atomicity is not implemented in [2] Wright, Matthew, and Adrian Freed. "Open Sound
the current VST specification. It is possible to Control: A New Protocol for Communicating with
atomically set plug-in parameters in the OSW wrapper Sound Synthesizers." Paper presented at the
by connecting them up to synchronous source, such as International Computer Music Conference,
an OSC bundle. Thessaloniki, Hellas 1997.
This paper has dealt exclusively with control of [3] Waves Ltd. Digital Audio Processing, IR1
VST audio plug-ins, but OSC would be similarly helpful Parametric Convolution Reverb, [Link]
in managing control of VST Instruments. Also, the com/[Link]?id=1564, 4 March 2005.
control structure recommendations are applicable to [4] Torkington, Nathan. Regular Expression Pocket
other formats of plug-ins, such as AU, TDM, or RTAS. Reference. Sebastopol, Calif. ; Farnham: O'Reilly,
The DSSI API already uses OSC for two-way 2003.
communication with LADSPA plug-ins. [10] The [5] Maxim Digital Audio "Freeverb" [Link]
“Generalized Music Plug-in Interface” (GMPI) protocol [Link]/, 5 March 2005.
attempts to define the interface between a broad range [6] Wolek, Nathan “Griesinger 2.2” [Link]
of plug-ins and hosts, and uses an “OSC-like” naming [Link]/, 5 March 2005.
scheme. [11] [7] Maxim Digital Audio "mda MultiBand" http://
The examples presented are intentionally www. [Link]/, 5 March 2005.
simple, as a complete exploration of mapping literature [8] Zbyszynski, Michael "OSC Control of VST Plug-
is beyond the scope of this paper. [12] However, the ins." Poster presented at the Open Sound Control
OSC implementations described above could be easily Conference, Berkeley, CA, USA, 2004.
extended to more complex mapping strategies. [9] Native Instruments GmbH [Link]
[Link]/, 10 March 2005.
5. CONCLUSIONS [10] DSSI, [Link] 20 June 2005.
[11] GMPI Working Group “GMPI Requirements – final
Currently, the control structure for VST plug-ins is draft proposal.” [Link] 20
disadvantaged by a limited, flat name space. When June 2005.
using multiple plug-ins, users must remember idiomatic [12] Hunt, Andy, Marcelo M. Wanderley, and Ross Kirk.
names for generic parameters, and navigate through "Towards a Model for Instrumental Mapping in
values that have all been mapped to the same range. The Expert Musical Interaction." Paper presented at the
usefulness of plug-ins in general could greatly improved International Computer Music Conference, Berlin,
Germany 2000.