Learn Audio Plugin Target Overview

Getting Started

Welcome to RNBO


RNBO Basics

Key Differences

Why We Made RNBO

Coding Resources


Audio IO

Messages to rnbo~

Using Parameters


Messages and Ports

Polyphony and Voice Control

Audio Files in RNBO

Using Buffers

Using the FFT

Export Targets

Export Targets Overview


Audio Plugin Target Overview

Exporting to the Audio Plugin Target

Max External Target
Raspberry Pi Target
The Web Export Target
The C++ Source Code Target

Code Export

Working with JavaScript
Working with C++

Special Topics

Sample Accurate Patching
Scala and Custom Tuning

RNBO and Max for Live

RNBO Raspberry Pi OSCQuery Runner


Export Description

Raspberry Pi GPIO

Updating the RNBO Package

Audio Plugin Target Overview

The Audio Plugin Export Target allows you to export your rnbo~ patcher as a VST plug-in or an Audio Unit (AU) Plugin.

An Audio Plugin extends the functionality of a Digital Audio Workstation (or other sound processing application) by adding new MIDI instruments or audio effects. The Audio Plugin export target lets you take your RNBO patch and export it as a plugin that will run in any application that supports audio plugins.

What's supported?

RNBO can export an audio plugin for use on a Mac, Windows, or Linux system. It can generate .vst3 files or Audio Unit .component files and, since code is compiled in the cloud, you can create a plugin that will run on any operating system you like, no matter what operating system you're using.

The meta attribute

The Audio Plugin target uses Parameter Metadata and the meta attribute to customize the behavior of parameters and audio inputs/outputs. This lets you create audio busses—useful for sidechaining—and add information to your parameters that the plugin host can use.

Audio Busses and Sidechaining

in~ and out~ : @meta bus:'<name>'

Audio inputs and outputs can be named and grouped using the bus property via the meta attribute. All in~ objects default to the bus name "input" and all out~'s default to "output" unless specified. Multiple consecutive in~ or out~ objects with the same bus name will be grouped and treated as part of the same bus. For example in~ 3 @meta bus:'sidechain' will create a mono input bus called "sidechain" in the exported plugin. Adding in~ 4 @meta bus:'sidechain' would result in a stereo input bus. Additional inputs could be added to create something a 5.1 layout.

Most DAW's will expect the inputs/outputs in any given group to be consecutive, so in~ 3 @meta bus:'foo', in~ 4 @meta bus:'bar', followed by in~ 5 @meta bus:'foo' is likely to result in a broken layout or even an unloadable plugin. The specific rules and requirements may vary based on the host DAW. It's also worth noting that many DAW's are able to detect standard channel layouts like mono, stereo and 5.1 based on the number of inputs in a bus and will sometimes incorporate this into their UI.

Version Hinting

param and @meta "{'versionhint' : <index>}"

JUCE plugins use versionhint to help keep parameter ID's consistent across versions of a plugin and are an important part of maintaining backwards compatibility when updating a plugin to a new version. The param object can set the versionhint value using the meta attribute. In general you want to increment the versionhint value of all parameters by one for each release. For example, if a plugin has a parameter foo, param foo @meta "{'versionhint': 1}" , this (and all other parameters) should be changed to param foo @meta "{'versionhint': 2}" for the next release. At the time of this writing the default value is 0 if a version hint isn’t specified.

For details see: 

https://docs.juce.com/favicons/favicon-16x16.pngJUCE: AudioProcessorParameter Class Reference


[param foo @meta "{'automate': false}"]

By default, all parameters have automation enabled. This allows the plugin host to change the parameter value continuously, for example by binding that parameter to an automation curve. However, there are situations in which you will want automation to be disabled. For example, if you were using RNBO to make a pitch tracker, you might want to use a parameter to display the output of pitch analysis. In this case, it wouldn't make sense to allow automation for this parameter, since the parameter is only used for output. To achieve this, use the metadata {'automate': false} to disable automation for the parameter.


[param foo @meta "{'notify': true}"]

By default, all parameters have notification set to true. This means that when a RNBO parameter changes, it notifies the host about those changes.

⁠Note that in earlier versions of RNBO (before 1.2.5), automation may behave in an unexpected way with notification enabled, since the automation will create superfluous notifications about parameter updates that may break automation. For that reason, you might want to set notifcation to false. However, if you are using a parameter as output, for example to report the output of pitch tracking analysis, then you may want to have notification for that parameter, which will enable the host to see and respond to updates to that parameter that come from within RNBO itself.

This should not be an issue in versions of RNBO after 1.2.5.

A note about distribution

It is possible to distribute your RNBO-exported VST with a license from Steinberg, or by open sourcing the project. In addition, you will need to follow some steps in order for your plugins to run on another macOS machine. For more information on both of these points and more, check out the RNBO Export Licensing FAQ.