Using multiple NetVSTHost instances

It IS possible to run multiple instances of NetVSTHost on different ports. The problem (my fault) is that the GUI doesn't display which IP/port a given instance is using, so when you have several open at once, it's hard to keep track of which is which.

The last IP/port you set gets saved to the Registry as a convenience, but if you open a second NetVSTHost, its attempt to open the same port will fail, so you can just go ahead and set a different port number.

If you go back to the first NetVSTHost instance and select Devices->Network, it will show the updated values from the Registry, but the program won't attempt to use them unless you click OK. If you click Cancel, it keeps using whatever it was using before.

I'm sorry this is so confusing. I had a look at the code today, to see if I could add the current IP/port to the NetVSTHost window title (to help you keep track of which instance is which), but I didn't succeed. That code is old, very complex, and wasn't written by me. (Which is why I have never published it.)

Until I have time to create a newer alternative NetVST host program (or figure out how to display IP/port in the existing one), you will need to find your own ways to keep track of the settings for multiple NetVSTHost instances. For example, I suggest you create them one at a time, assign them increasing port numbers, e.g. 27016, 27017, etc., and lay out the windows in a corresponding order, so port numbers increase from left to right or top to bottom.

UNIFY: Commercial product with NetVST built-in

For nearly a year, I've been working on my first commercial music software product, called Unify. This may be of some interest to readers of this blog, because the "Pro" version of the product will have NetVST technology built-in.

This post isn't meant to be an advertisement. It's more of an explanation for why I haven't updated the NetVST software recently. Hopefully, I'll be able to get back to that after Unify is released by October of this year.

I'd like to assure everyone that NetVST will still be available, and will remain free. For many of you, NetVSTHost and the NetSynth/NetFilter plug-ins are all you need, and you should continue using them indefinitely.

A few of you might be interested in Unify's additional capabilities for creating composite sounds, and I invite you to have a look at the press release and associated YouTube videos (many more of which are coming from my colleague John Lehmkuhl of PlugInGuru.com).

macOS Catalina: the end of 32-bit VST support?

This past week, I received a flurry of emails from software vendors, advising Mac users to hold off updating to macOS Catalina, because it won't support 32-bit binaries at all.

Most significantly, one of these emails came from CodeWeavers, makers of CrossOver, an excellent commercial implementation of WINE--the same technology which powers NetVSTHost for Mac. They included a link to their own blog post which explains why this issue is so thorny.

The heart of it is this:

Most Windows applications our users run with CrossOver are 32-bit and CrossOver uses a 32-bit Mac executable, system frameworks, and libraries to run them. This will break with Catalina.

So, even if I were to repackage NetVSTHost for Mac using the most recent 64-bit version of WineBottler, the resulting 64-bit binary would run under Catalina, but would only be able to run 64-bit Windows VSTs. In my view, this undermines the most important use-case for NetVSTHost for Mac, so I see little point in pursuing it.

NetVSTHost for Mac was never much more than a convenient little hack--a way to run the 32-bit, Windows-based NetVSTHost.exe program on a Mac, without having to set up a full virtual machine (using e.g. VMWare Fusion, Parallels Desktop, or the Mac version of VirtualBox), or better yet, use an actual Windows PC.

I would advise anyone who has come to rely on NetVSTHost for Mac, and who anticipates upgrading to macOS Catalina at any time, to look into the two-system approach for which the NetVST Project was originally conceived. Details can be found on the NetVST Project wiki.

NetVST is now part of AudioKit

AudioKit is an open-source framework to facilitate audio/music app development on Apple platforms, including Macintosh OSX, iPhone and iPad. I was recently invited to join the AudioKit core team, and I'm focusing my effort on expanding the "core" parts of the framework to other platforms, including Windows and Linux.

To this end, I've created a new code repository on GitHub called AudioKitNet, where I'm exploring how plugin vendors can modify their existing plugins to allow the DSP work to be done on servers.

NetFilter/NetSynth now have custom GUIs

Originally, the NetSynth/NetFilter plugins didn't provide a custom GUI, so you were stuck with whatever generic GUI your DAW provided. This turned out to be very clumsy for entering IP addresses and port numbers.

As of the December 24, 2017 update, both the AU (Mac) and VST (Windows) plugins provide a simple GUI to specify the IP address and port number for the remote server (NetVSTHost instance).

The Windows GUI looks like this, and you enter a single string e.g. 192.168.1.100:27016, then hit Update.

Windows GUI

The Mac GUI is almost the same, but has separate input boxes for the four IP address numbers and the port number; otherwise, it works the same.

enter image description here

NetVSTHost now runs on the Mac!

NetVSTHost is written for Windows, but the .exe can run under Linux and Mac OS using Wine. Setting up Wine to run 32-bit, network-capable .exe's under a 64-bit operating system can be a challenge, to say the least. However, thanks to Mike Kronenberg's incredible new WineBottler tool, the whole process is largely automated, yielding a standard Mac OS app bundle, which can be double-clicked just like a native Mac application, and opens NetVSTHost (running inside Wine). Color me impressed!

Don't mix LAN speeds

I tried running NetVSTHost on a 2014 HP Windows laptop, connected to a very new gigabit-Ethernet switch along with an older Mac Mini client, and the performance was terrible!

It turned out that although the old, Core Duo Mac Mini from 2006 had a gigabit Ethernet port, the much newer HP laptop only had a 10/100 port. As a result, the switch had to fully receive each packet and re-send it at the different speed -- in both directions -- resulting in huge latency.

The lesson is, make sure all devices on your NetVST LAN are running at the same speed -- preferably 1 gigabit/sec.

CPU usage hugely reduced

I'm very happy to report that by rearranging the order of network operations slightly, I have been able to bring the plugins' CPU usage down to essentially zero.

The original NetVST implementation was pretty good, but CPU usage of the plugins (especially on the Mac) was stubbornly high, around 15%. At that rate, it didn't seem practical to use many plugin instances. With the newest implementation, this issue is gone.

Head to the wiki downloads page to get the updated NetVST and plugins. Note you must update both the NetVST Windows executable and all NetVST plugins, because this change breaks backward compatibility.