MuLab supports VST2, VST3 and CLAP plugins.
Using plugins is similar as using the internal MuTools modules, though here are some specific aspects.
That's what this doc page is about.

 

How to insert a plugin

On MacOS a VST2/VST3/CLAP plugin is a shared library normally with extension ".vst" or ".vst3" or ".clap".
On Windows a VST2 plugin is a DLL normally with extension ".dll" while VST3 plugins have extension ".vst3" and CLAP plugins extension ".clap".

There are several ways to start using a plugin:

• You can drag-drop the plugin file on a rack slot or MUX Modular Area.
• You can add plugins via MuLab menu -> Plugin Manager.
• Known plugins will be available in the plugin list when you click an empty rack slot or add a module in the MUX Modular Area.
  And if the plugin you want to use is not yet listed there then choose "Browse For Plugin..." in that popup list.

 

About VST2 inputs and outputs (does not apply to VST3/CLAP)

A VST2 plugin can have multiple audio inputs and outputs. Each VST2 audio input and output jack is mono, that's how VST2 is organized. But there is a VST2 function where the plugin can tell the host how its inputs and outputs are practically organized. If a VST2 plugin has, for example, 2 output jacks and it reports to the host that they're the left and right jack of a single stereo signal, then MUX Modular will present these 2 VST2 plugin jacks as a single stereo jack, as that's what the plugin suggests. MUX Modular still offers you a way to override that by using a Stereo Splitter or Stereo Combiner, so, continuing the above example, if you want to have 2 separate mono outputs for that VST2 plugin, you can use a Stereo Splitter module.

If there are VST2 plugins for which you would want a more permanent reorganisation of its audio inputs and outputs, then you can use the ReGroupAudioInputs and ReGroupAudioOutputs preferences in the VstPlugins.xml file. More details on the Preferences doc page.

 

Using multiple inputs and outputs

When inserting a plugin into a rack, you don't immediately see the extra inputs/outputs of a plugin. If you want to have control over these auxiliary inputs/outputs there are 3 options:

• Insert a MUX in that rack and then insert the plugin in that MUX.
  Then in that MUX's modular area you'll see all the inputs/outputs of the plugin and you have all creative freedom to use them as you want.
  Also note that another advantage of working this way is that you can save this MUX as a preset that can be re-used in other projects, for example you can make plugin presets that include a complete sub-mix setup!
• Right-click the plugin in the rack slot and choose "Setup Aux Ins/Outs".
  Then you can choose which auxiliary inputs/outputs should be imported/exported from the rack.
  When that's done the rack will have the extra inputs/outputs that directly represent the auxiliary plugin inputs/outputs.
  Then go to the modular area containing that rack and there you can connect things as you want.
  If you want certain plugins to always import/export certain auxiliary inputs/outputs whenever it's plugged in, you can define this in the MuLab menu -> Plugin Manager -> right-click the plugin -> Edit Extra Options. This avoids having to do "Setup Aux Ins/Outs" again and again if you want that to be default behavior.
• Insert the plugin in the modular area and connect things as you want, similar to the first option, but here you can also add racks to the plugin outputs and so these racks will also show up in the rack desk.

 

Auto Bypass

Using the Auto Bypass function you can avoid wasting precious CPU cycles by temporarily bypassing plugins that are only processing silence.
It means that if the plugin is not receiving any input nor generating any output for some time then the plugin is bypassed so that it does not consume CPU.
As soon as the plugin receives input again, the auto bypass is switched off and the plugin processes the input, so nothing lost, only CPU gain.
This works for both plugin effects and synths!  
The Auto Bypass can be setup via the plugin's context menu.
The value is the number of milliseconds that the output must be silent before the Auto Bypass is switched on.
By default it's set to "Off", but by setting the "Auto Bypass Threshold" to eg 500 ms then the auto bypass will be switched on as soon as the plugin's output is silent for 500 ms and the plugin does not receive any new input.
Of course it depends from plugin to plugin, and even from patch to patch what threshold value is best.
Just as an example: A filter plugin may be ok with a threshold of 10 ms, but a delay plugin will need a threshold that is at least as long as the delay time.
 
The Auto Bypass setting can be defined per plugin instance. (as it might depend on the specific plugin preset)
The default setting can be defined globally in the app preferences as well as per plugin in the Plugin Manager.
 
When the Auto Bypass function is enabled and it is effectively switched on (thus bypassing silence) the power LED for that plugin is dimmed, indicating that the plugin is still active but auto-bypassed.
That way you can clearly see the Auto Bypass function in action.
 
Note that some plugins constantly send out a very low-level unhearable noise so to avoid floating-point denormalization, but these redundant floating-point values do consume CPU.
To bypass that there is the "Plugin Silent Output Threshold dB" preference, which can be defined globally in the app preferences, as well as per plugin in the Plugin Manager.
 

Focused Plugin Parameter Control

At the top of each plugin editor, at the right of the Open/Save and Options buttons, there is a parameter knob that reflects the last tweaked plugin parameter. Whenever you tweak a plugin parameter that focused parameter control switches to that last tweaked parameter. This focused parameter control is a handy bridge between any plugin parameter and the MuLab GUI. For example you can easily drag-drop the name of that focused parameter control onto the [+] track button to create an automation track, or to insert a point for that parameter value into an automation envelope editor, etc. You can also right-click the focused parameter control for handy functions like Copy As Parameter Event, Copy As Envelope Point, Map MIDI Controller, etc. It can also be used to monitor the value of parameters for plugins that don't show this in their own editor. It can also be used to copy-paste VST parameter values even in plugin editors that don't support such functionality. Etc.

 

How To Automate A Plugin Parameter

• Open the plugin editor.
• Give a little tweak to the parameter you want to automate. This will switch the focused parameter control to that parameter.
• Drag-drop the name of that focused parameter control onto the [+] track button in the composer.

Alternatively, if you already have a track for that plugin, right-click the track and choose "Add Automation Sub-Track".

 

How To MIDI Control A Plugin Parameter

• Open the plugin editor.
• Give a little tweak to the parameter you want to control.
• Open the plugin context menu via the Options button at the top of the editor.
• Choose "Map MIDI Controller". You'll see that the last tweaked parameter is already selected; but you can also choose another one if you want.
• Move your preferred MIDI controller or select it manually from the list.

 

MacOS: How to drop files from the finder onto a plugin editor

Drag the files from the finder window, drag-hold over the MuLab icon in the Mac doc, the MuLab window re-appears, then drag-hold over the MuLab window, the plugin windows re-appear, then you can drop the samples on one of the plugin windows.

 

32 bit and 64 bit

MacOS and Windows do not allow loading 32 bit plugins into 64 bit hosts and vice versa.
So make sure the plugins you want to use have the same bit-depth as the MuLab you're using.
If such version does not exist for a specific VST plugin then you could try jBridge.

 

About Keyboard Focus

Generally operating systems send key presses to the focused control in the focused window. When that control does not handle that key press it should forward it to the next keyboard handler, eg. its parent control. If all controls properly follow this rule, all will work fine as the user can indicate which control must have keyboard focus. That's how it technically works. Correction: should work. Read on.

By default MUX tries to give key focus to the plugin editor, but it also depends on how the plugin editor works.
So when using plugin editors then sometimes it's not clear who has the keyboard focus: The MUX window or the embedded plugin editor.
That's because some plugins grab focus, others don't. And as a user sometimes you want keyboard focus on the MUX window (to use MUX key shortcuts) or on the plugin editor (to use that plugin editor's key shortcuts). To have more control over where the keyboard focus is when using a plugin editor there are 2 functions:

• In the MUX window options menu there is "Set Key Focus To Plugin Editor" which will set the keyboard focus to the embedded plugin editor.
  Still it depends on the plugin whether this will work.
• When clicking on the MUX background of the top control bar of a plugin editor window, then the keyboard focus is set to the MUX window.

Unfortunately there is an extra complication wrt using key shortcuts in plugin editors: When the key focus is on the plugin editor and you use a key shortcut for MUX, and that key is not used by the plugin editor, it should be forwarded to the MUX window so that the key shortcut can be processed by MUX. But it occurs that the plugin editor does not properly forward unhandled keyboard events and this may result in, for example, that while the keyboard focus is on the plugin editor, pressing the spacebar does not start/stop the main Play function. And besides that, there also is a non-comformity in Microsoft Windows: When a child window (the very plugin editor) does report that a key press is unused and hence it gives the key message to DefWindowProc, Windows does not forward it to the parent window.
That's a serious shortcoming in the Windows system.
MuLab cannot do much about these cases except for this workaround: When you click the top control bar of a plugin editor (thus in the MuLab GUI area) this will shift the GUI focus to the window's top level and hence key presses will be processed by MuLab.
So that way you can quickly force a GUI focus shift to the MuLab GUI and hence eg pressing the spacebar will start/stop playing the composition.

 

Plugin Files, Plugin Items, Plugin Names

Since MuLab 10.1 there are plugin files and plugin items.
A single plugin file can contain many plugin items.
This somewhat complicated difference is not MuLab's choice, it's how VST3 and CLAP are designed.
VST3 and CLAP allow a plugin developer to store multiple plugins inside a single DLL file.
 
So at least there is a plugin file name and a plugin item name.
By default the plugin file name equals the real file name itself, without extension.
But it could be, for your good reasons, that you have multiple versions of the same plugin in different folders.
These plugins would be shown with the same name in MuLab's Plugin Database making it difficult to differentiate between them.
That's why MuLab supports renaming the plugin file within the MuLab database.
The real file on disk keeps the same name (changing that could be problematic to some plugins) but you can give the DLL file a custom name within MuLab's plugin database.
A plugin item ( = a real plugin inside a plugin file) has a default name given by the plugin developer.
As some plugin developers give odd names, or names you don't fully like, or names that may be ambiguous to other plugin names, MuLab also supports renaming the plugin item.
The project browser lists the usable plugin items, not the plugin files.
 
Renaming the plugin file name is rather exceptional, and is only be possible via the options button in the Info frame of the Plugin Manager.
The plugin file name is an important because it's part of the data that is saved + reloaded so to retrieve the exact same plugin.
 
Generally: It's recommended to not use custom plugin file names, unless you're an advanced user and know what this is about.
There could also be legacy reason because custom plugin names were more liberal in MuLab 8, MuLab 9 and MuLab 10.0.

 

Plugin Manager Notes

• You can indicate plugins as Favorite, which will show them at the top of the list.
• You can categorize your plugins into groups (eg. "VA Synths", "Samplers", "EQ & Filters", "Reverbs", ...) which will show them in groups.
• You can sort plugins per developer.
• You can drag-drop files on the plugin manager to add plugins.<
• You can drag-drop list items from the project browser to sync the plugin manager list view.
• You can drag-drop list items from the plugin manager to tracks, racks, modular areas, ... the same way as can be done from the project browser.
• While scanning, MuLab stores the name of the next plugin that will be scanned in the PlugFileBeingScanned.txt file in your User/LogFiles subfolder.
  When this plugin scan has successfully ended this file is deleted. However when the plugin scan would crash, a next MuLab session will detect this by the existence of this file and memorize the crash issue of this plugin.
• The "Always Reset Editor Window" option tells a plugin that its editor must be fully reset every time it's closed/reopened.
  This might fix editor issues caused by certain less compliant plugins.
  Attention: Switching this on/off will only have effect after re-inserting the plugin.

 

Extra Notes

• A plugin is a dynamic library file, on Windows called a DLL file, on MacOS called a bundle. Now when scanning plugins, it may be that also other DLL/bundle files are detected and scanned to see if they're plugins. In case a DLL/bundle is not a plugin the scan log will include a message that it cannot recognize it as a VST2/VST3/CLAP plugin.
• Input and output names for stereo jacks are displayed in a simplified form, for example if the plugin reports that the output names for a stereo output are "Output 1" and "Output 2" then the tooltip for that output wil say "Output 1+2".
• VST2 shell plugins are not supported. But you can try this workaround: Shell2Vst
• You can drag-drop an FXB/FXP file on the top control bar of a VST2 editor, that will load that FXB/FXP file into that VST2.
• You can drag-drop an FXB/FXP file on the top control bar of a VST2 editor, that will load that FXB/FXP file into that VST2.
• If there is a project or preset file that fails to load and it's using plugins then you can try rescue the project by skipping loading plugins one by one.
  To do so go to the main MuLab menu -> Tools -> Command Line and enter "confirm load plugins". Then retry loading the project.
  You can toggle this switch again by entering the same command.
  This switch stays the same until you quit MuLab.
  On restart this switch will be off again.