Plug-ins

Plug-ins

*This chapter covers the general principles of plug-ins in Mixbus. To learn about using plugins in your mix, visit Using Plug-ins

Mixbus can load plug-ins in several formats, depending on your platform. Mixbus can only use plug-ins that meet these criteria:

• The plug-in must be a supported format on your OS (see below)
• The plug-in must be compiled for the same platform as the Mixbus you are running. ( for example, 64bit Mixbus loads 64bit plug-ins, but not 32bit plug-ins )

!It is Harrison’s intent to support every plug-in available, whether commercial or free. However there are many reasons why a third-party addon might not work in Mixbus, or might crash, or might behave unexpectedly. This is true of any DAW.

A summary of plug-in support in Mixbus:

Apple^TM AU plug-ins (supported on OS X only)

AU (Audio Unit) is the native (Apple-developed) plug-in format for OS X. Most commercial plug-in developers make AU plug-ins for Mac, because this is the native format for Apple’s Garageband and Logic.

Unlike other formats, AU plug-ins normally provide a “variable” number of inputs and outputs. The host (Mixbus) must tell the plugin how many inputs and outputs we want, and then the plugin can respond whether that is a valid choice. This can get quite complicated. Mixbus chooses the I/O based on the number of signal “pipes” at the insertion point of the plug-in.

Scanning of AU plugins must be initiated manually in Mixbus->Preferences->Plugins. If a plugin causes Mixbus to crash during the “scan” procedure, then this plugin will be placed on a “blacklist” which prevents that version of the plugin from scanning in the future.

Steinberg VST plug-ins (supported on all platforms)

VST (Virtual Studio Technology) plug-ins were developed by Steinberg ^TM and are the most common plug-in format on Windows. VST plug-ins can be developed for Windows, OS X, and Linux.

VST plugins typically come in 2in/2out versions (stereo I/O). Mixbus channels are typically mono or stereo; but the signal width can vary in the redirect sections. Mixbus will try to accommodate the audio and MIDI “pipes” that are present in the signal flow at that location. For more details, see Processor Signal Flow.

Scanning of VST plugins must be initiated manually in Edit->Preferences->Plugins. If a plugin causes Mixbus to crash during the “scan” procedure, then this plugin will be placed on a “blacklist” which prevents that version of the plugin from scanning in the future.

Unlike AU and LV2, the VST specification does not specify where plugin files should be installed. When using VST plugins, you must take note of the folder location that the installer reports. You may find it easier to redirect the installer to one of the default locations that Mixbus uses. You can find these locations in Preferences>Plugins>VST>Path.

Or you can create a new folder of your liking and install all of your plug-ins there. This way Mixbus has to scan fewer folders. For every new folder created, Mixbus has to be made aware of its existence. If you have 20 different folders, then it places a burden on the user to inform Mixbus of their locations. Simplifying the plugins location upon installation may prove useful.

Steinberg VST3 plug-ins (supported on all platforms)

VST3 plug-ins were developed by Steinberg ^TM as a successor to the VST format. VST3 plug-ins can be developed for Windows, OS X, and Linux.

VST3 improves on the VST2 spec with more flexible I/O choices, sample-accurate automation, logical parameter organization (for automation). https://www.steinberg.net/en/company/technologies/vst3.html

Unlike VST, it is not necessary to define the installation folder for VST3’s. The installation path is predefined for all manufacturers.

LV2 plug-ins (supported on all platforms)

LV2 is the “next generation” open-source plug-in format. LV2 plug-ins have several advantages over other formats. For example, LV2 plug-ins do not have to be instantiated to be scanned, so startup is much faster and less likely to crash. For developers, LV2 is completely unencumbered by licensing restrictions. Harrison’s bundled plug-ins currently use the LV2 format, and the same plug-ins operate on Windows, Mac, and Linux. This allows you to share sessions with users on other platforms, and have your sound remain unchanged.

LADSPA plug-ins (supported on all platforms)

LADSPA is the “Linux Audio Developer’s Simple Plug-in Architecture”. LADSPA plug-ins are simple to develop and are freely available. LADSPA plug-ins do not support customized GUIs. The “generic” GUI will provide sliders and knobs on a simple window. Being very portable, most LADSPAs are available for all platforms (OS X, Linux, and Windows). LADSPA makes an excellent starting point for developers that want to learn plug-in development. The quality can vary significantly, but there are a few good plug-ins available.

Mixbus can load a mono LADSPA plug-in into a stereo channel (by duplicating the plug-in and assigning the same controls to both sides of the signal). This works well for some plug-in types (such as EQ) but less well for compressors, which might introduce a shift in the stereo image if they aren’t truly stereo. In these cases, you should choose a stereo LADSPA, not a mono one.

Digidesign AAX/TDM/RTAS plug-ins (no support currently).

AAX, RTAS and TDM plug-ins are proprietary formats for Pro Tools ^TM. Mixbus does NOT support RTAS or TDM plug-ins. It is unlikely that Mixbus will ever support AAX, RTAS or TDM plug-ins.

Windows DirectX plug-ins (no support currently)

The DirectX plug-in API was developed by Microsoft and is the native plug-in format for Windows. Few professional plug-in manufacturers provide DirectX plug-ins, so Mixbus does not currently support DirectX plug-ins.

*Note: While we have taken care to follow the specifications for each plug-in format, plug-ins are developed by third-party vendors. This means that Harrison cannot take responsibility for plug-ins that don’t work as expected. Please use caution when trying a plug-in for the first time. Verify that all the functions work as expected before committing to using a particular plug-in in a session.

Latency Compensation

Some plug-ins, particularly plug-ins that use hardware “accelerators” or convolution-type processing, can cause significant latency (time delay) from the input to the output. This can cause problems if the delayed signal is mixed with a signal that is not delayed. A long delay can cause the tracks to sound “out of time”, while a very short delay can cause comb filtering (“phasiness”). Mixbus can automatically accommodate plug-in and insert latencies for you. To do this, Mixbus delays the non-affected tracks to match the track with the longest latency. Please be aware of these facts:

• Adding or bypassing a plugin can change its latency. Some plugins have internal controls (like “lookahead”, “oversampling”, or “quality”) that change their latency.
• Latency offsets are recalculated when you “stop” the transport. So if you hear a delay or phasing caused by plugin latency, try stopping and restarting playback.
• Tracks can accommodate “unlimited” latency by buffering the audio from disk earlier than it is needed.
• Mix buses are limited to 8192 samples of latency compensation. If the total latency of all plug-ins in a mix bus exceeds 8192 samples, then a time offset will occur.
• “Buses” created with the Add Track/Bus dialog (we call these “utility buses”) do not support latency compensation.

Harrison Consoles Copyright Information 2023
No part of this publication may be copied, reproduced, transmitted, stored on a retrieval system, or translated into any language, in any form or by any means without the prior written consent of an authorized officer of Harrison Consoles, 750 Jim Parker Drive Smyrna, Tn 37167.