Awesome

LinVstManager

LinVstManager is a companion application that allows managing VSTs in conjunction with various VST bridges created by osxmidi.

Motivation

LinVst (for example) requires something like the following setup:

1. Install the bridge
2. Install your desired VST in a wine prefix
3. Copy the linvst.so file template to the VST's location and rename it to {NameOfVST}.so
4. Optinally make a softlink to another folder (let's call it a link folder), so you can point your DAW to one central location for loading bridged VSTs.
5. If at some point there is an update of LinVst you want to give a try, you gotta:
   1. Install the new bridge version
   2. Replace the *.so files alongside all bridged VSTs (the ones bridged with LinVst)

Now chances are that you have bridged more than one VST and possibly even with different bridges depending on if they are VST2 or VST3 and if they need to be able to communicate with each other or not.

Handling this all manually can take time and be error prone (i.e. version conflicts when starting up your DAW and some VSTs not loading).

Some time ago this already caused me to create linvstmanage-cli; a config file and cli-based UI that together allowed to at least manage VSTs bridge with one bridge type (initially there was only LinVst, not -X, 3, or 3-X). It was sufficient if all you needed was one bridge type and maybe had something like 30 VSTs bridged.

After that, the cli-based UI quickly becomes a bit of a chore to use. Furthermore there were requests for a scan feature (like most DAWs have), which allows to scan for VSTs instead of locating each one manually.

All this and the increase of bridge types kinda made linvstmanage-cli somewhat lacking.

That's why LinVstManager was created:

Features

• currently supported bridges:
  • LinVst
  • LinVst-X
  • LinVst3
  • LinVst3-X
• Batch adding of VSTs:
• Scanning for VSTs (verification of *.dll files actually being VSTs)
• GUI and shortcut driven user interface
• No more manual config file editing (as was the case with linvstmanage-cli)
• Update/Create *.so files for all tracked VSTs
• Enable/Disable VSTs by adding/removing a softlink to the respective *.so file. All softlinks are mapped to a link folder which can be scanned by your preferred DAW.
• Detection and optional removal of orphaned *.so-links/files in link folder
• Regex based search of table entries
• "Blacklisting"
• and more...

Dependencies

If you've already managed to build LinVst, then pretty much only:

• Qt5 for the graphical LinVstManager application

Building the source

Nevertheless, here are some distributions and the needed packages:

1. Install required packages based on your distribution:

• Archlinux / Manjaro:

  An AUR package does exist: See here.

  Alternatively install the following for proceding with the manual install:

  sudo pacman -S cmake make gcc git qt5-base
  

• Fedora 31:

  sudo dnf install cmake make gcc gcc-c++ git qt5-devel
  

• Ubuntu 19.10:

  sudo apt install cmake make gcc git qt5-default
  

• Ubuntu 18.04:

  sudo apt install cmake gcc g++ git qt5-default
  

• Ubuntu 20.04:

  sudo apt install cmake g++ git qt5-default
  

2. Two options to get the sources:

   • option a): Download a release from the release page and unpack it.

   • option b): Clone this repository to get the latest development version:

     git clone https://github.com/goli4thus/linvstmanager
     

3. Change into the downloaded folder and run the following in a terminal:

mkdir build && cd build
cmake ..
make -j4
sudo make install

6. Now you should be able to launch LinVstManager like any other graphical application.

Usage

First start

After having acknowledged that there can't be a config file on the first start of the application, there's another message regarding closing your DAW before proceeding. This is more important later on when you've already added some VSTs, because removing existing bridges (*.so files) that a running DAW has loaded, will most certainly crash the DAW.

Setting all up

Now the first thing should be to open Option -> Preferences:

Bridges

Here you can setup one or more of the mentioned bridges. Specifically the location of the *.so template files.

Defaults

When it comes to adding VSTs, choices got to be made which bridge should be used. Here some default values can be specified.

General

• Link folder: The folder where all softlink will be created in and therefore the only location your DAW needs to be pointed at to "scan". It's assumed that the specified folder is a dedicated folder which is only being used by LinVstManager (otherwise the feature orphan detection will remove the VSTs not managed by LinVstManager if being told during startup to clean up orphans).

After all that, take a moment and explore the menu bar. Some operations are also available via right mouse click. Furthermore every operation can be done using a keyboard shortcut as well.

If you've been using linvstmanage-cli previously...

... you're in luck. Try File -> Import legacy config and locate the previous config file linvstmanage.ini (by default located in '~/.config/linvst/manage/'. Once selected, it will be parsed and all previously set up VSTs will be added into LinVstManager.

Manually adding VSTs

Choose Edit -> Add VST and locate one or more VSTs which shall be added.

Scanning for VSTs

Choose Edit -> Scan and give the text on top of the dialog an initial read. Everything is explained there.

During the scan a progress indicator is shown which represents the actual scan progress. Furthermore there are three counters indicating in realtime what is being found.

Hint: Once a scan is done and the results are shown in the dialog's table, the entries can be filtered the same way as in the main table. Entries need to be selected (see right click menu) before they can be added. This allows to make a sub-selection of what was found (or just Ctrl-a, select, add).

Scan verification

Compared to simply adding VSTs via the respective menu actions, scanning can actually make use of a verification feature.

In general, *.vst3 files are not being verified, as they are obviously VST files.

Here's what will happen depending on the "verify" selections you make within the scan dialog.

Verification disabled

All encountered *.dll files will be considered a match and be shown in the results table (marked as being unverified though).

Verification enabled

Only encountered *.dll files that pass the verification will be shown in the results table. The found VSTs will have a probability attached to them:

Once VSTs are added,...

... their status will be No *.so initially.

Performing an update will create accompaning VST-so files for each VST.dll. This results in the status of all VSTs becoming Disabled.

After that the VSTs can be Enabled, which creates softlinks within the link folder referencing the previously created VST-so files.

This central link folder can be scanned by whatever DAW you are using.

Changing the bridge type

Select all VSTs you want to change to another bridge and use Edit -> Change bridge (also accessible via right click menu) and select the desired one.

A tip in general: There are lots of tooltips spread across labels, text fields, table headers, etc. Just hover your mouse over things that don't quite make sense and chances are there is some additional information.

Resolving naming conflicts

VSTs are being identified by their absolute path. This means that if two different VSTs are named the same (i.e. "EQ.dll"), they both can be added to LinVstManager. Consequently this results in a naming conflict, indicated by status Conflict. This can be resolved by using the rename feature:

Wait, are you really renaming my VST?

Well, not exactly. The renaming affects the name shown within LinVstManager. Apart from within the application, this name is used as the basis for creating the soft-links inside the link folder.

For example: Let's say we have two VSTs by two different vendors, both named "EQ". One of them will show up as a conflict once added to LinVstManager. This conflict can be resolved by renaming the indicated VST. Let's say to "EQ_VendorX". Once both of these VSTs are being Enabled, the link folder will contain two softlinks:

• EQ.so
• EQ_VendorX.so

If you are pointing your DAW to scan the link folder, both VSTs will be picked up.

But depending on your DAW, the result will be different. Some DAWs (i.e. Reaper) don't care what the filename of a VST is. The name (and vendor) shown in the FX browser are actually derived from what is set within the VST itself.

Other DAWs (i.e. Renoise, Bitwig) in contrast do actually care about the filename and will display "EQ" and "EQ_VendorX" in their FX browser.

Overall this won't affect functionality of a VST, but might actually allow you to elegantly resolve naming conflicts without having to alter the naming of *.dll or *.vst3 files.

Batch renaming

If you ever feel the need to batch rename multiple VSTs, there is another dialog available:

Here you can either add a phrase at the start or end of the selected VST's names or remove a desired amount of characters from them. Hint: Examine the tooltips of labels 'Mode' and 'Location' for more information.

Further notes

VST states

Notes:

• Only Enabled VSTs can be seen by your DAW scanning the link folder.
• States Mismatch and No *.so can both be resolved by performing Edit -> Update.
• If a VST is 'Blacklisted', operations like enable, disable, update all will have no effect on. it until that VST is 'unblacklisted' once again

Where is it all saved?

Everthing is being stored in a central config file:

~/.config/linvst/manager/linvstmanager_config.xml

As opposed to linvstmanage-cli, there's no need to edit this file manually. Everything is done via the graphical interface.

Further usability features

Filter bar

Apart from familiar table sorting features one can use View -> Filter to open up a search bar. This search consideres all columns and is regex based (case insensitive).

Hint: Imagine all columns of a row being combined to one long string with rows being separated by one space character (cause that's how it's implemented). This means you can perform searches like:

Sidebar

The sidebar on the right handside of the main window shows the amount of VSTs per status. Furthermore the colored rectangles are actuall buttons and once clicked on will setup the filter bar to filter for the respective status (same effect as if entered manually in filter bar).

Hint: Clicking the same button again will cancel the filter.

Further usecases

Updating or trying out different versions of a bridge

In case of updating or changing versions of LinVst (or another bridge), all that needs to be done is:

1. Install the respective bridge
2. Start LinVstManager and select the newly installed *.so template file with Option -> Preferences
3. Notice the resulting <i>No_So</i>; perform and Edit -> Update; all done

Blacklisting VSTs: Why?

Let's say you've narrowed down to a subfolder within a wine prefix, but there still seem to be many dll files that aren't VST files.

You could perform a scan without the 'verify' option. That would result in all non-VST-dll files being detected as VST2 files in addition to the "real" VST2 files. After that you could add/filter and blacklist those.

During subsequent scans these dll files would be ignored due to already being "tracked". In addition, 'blacklisted' VSTs won't interfere during other operations (i.e. enable all,...) and can optionally even be hidden via View -> Hide blacklisted.

Donations

If you find this project valuable and want to make a donation, you can do so using the following link: Donate via PayPal