One of my students appears to have latency issues when running it on a PC.
[vstplugin~]by itself doesn't introduce any latency. A VST plugin might have latency (as reported by the
[latency(message), but few actually do.
Have you checked your student's audio settings? Make sure that
- the student has installed the ASIO driver for their audio interface - or in the case of built-in mic/speakers, a generic ASIO driver like ASIO4all
- the ASIO backend ("ASIO (via portaudio") is selected
- the "delay" value is set as low as possible. Something like 10ms or lower should be ok. I think the default value is 50ms, which is much too high.
Sometimes it is also necessary to experiment with the hardware buffer size, e.g. setting it to 256 instead of 64.
Here's a new release of [vstplugin~] - a Pd external to load VST plugins on Windows, macOS and Linux!
Binaries are available on Deken or can be downloaded here: https://git.iem.at/pd/vstplugin/-/releases
If possible, please report any issues at https://git.iem.at/pd/vstplugin/issues, otherwise leave a comment.
NOTE: macOS users might consider using my Pd vanilla fork, where the VST GUI doesn't run on the audio thread. You can download binaries here: https://github.com/Spacechild1/pure-data/releases/tag/v0.51.1-eventloop. It is the same as Pd 0.51-1, but it offers the option to run a Cocoa event loop. Maybe this feature will make its way into a future version of Pd vanilla.
Here are the major new features:
automatic bit bridging (load 32-bit plugins on a 64-bit Pd and vice versa).
[open(: new flags "-p" for sandboxing and "-b" for bridging. Both options allow plugins to crash safely without taking down the Pd. This can be handy for buggy/unstable plugins (especially during live shows
[open(: new "-t" flag for multithreading (process plugins in seperate helper threads to utilize more CPU cores)
[latency(message is sent whenever the plugin's processing latency changes
See the release page for the full change log.
This is a critical bug fix release for vstplugin~ v0.3.0 (see https://forum.pdpatchrepo.info/topic/12500/vstplugin-0-3-0)
NOTE: If you’ve already been using vstplugin~, please upgrade and read the changelog below!
Binaries are available on Deken or here: https://git.iem.at/pd/vstplugin/releases .
Please report any bugs at https://git.iem.at/pd/vstplugin/issues or leave a comment.
- fixed wrong VST3 plugin ID. The main issue was that VST3 preset files couldn’t be opened in other VST hosts and vice versa.
NOTE: You can still open old “wrong” preset files, but this might go away in future versions, so you’re advised to open and save your old VST3 presets to “convert” them to the new correct format. But first you need to clear the plugin cache with
[search_clear 1(and do a new search to update the plugin IDs. Sorry for the inconvenience!
fixed possible crash when opening plugins asynchronously
fixed possible crash when quitting Pd (especially on macOS)
fixed crash with certain VST3 plugins when saving presets
disable window resizing if the GUI editor has a fixed size
- resizable VST3 GUI editors are now supported
The DSP is multi-threaded. It is supposed to be wait-free.
@Nicolas-Danet This sounds exciting! I have some questions:
- how do you handle concurrent garray reads/writes?
- how do you handle concurrent access to the clock list (e.g. calling
clock_setin the perform routine)?
- which API functions are safe to call in the perform routine?
I could probably find the answers by reading the source code, but maybe you could give some rough answers, so I know what I should look for
new browsers look like a work of art
thanks has been a huge headache till I got it working the way I wanted it (more or less).
has there been any further development on the macOS gui thread work?
Not yet. The thing is that it involves changes in the Pd core. I definitely want to do this but I have to coordinate this with GEM and ofelia which expect the Cocoa message loop to run on the audio thread. Once the audio thread is not the "main thread" anymore, those two externals will stop to work. Maybe a startup flag (e.g.
-noeventloop) can do the trick.
FWIW, on Supercollider the situation was even worse, because I couldn't show the plugin GUI at all, but I made the necessary changes to the Server code which will be available in the upcoming SC 3.11. I'm positive I can achieve the same for Pd vanilla. It will just take a while. In the meantime, thank Apple for their stupid arbitrary design decisions
I'm happy to announce the release of vstplugin~ v0.3.0.
[vstplugin~] allows to load VST2 and VST3 plugins on Windows, macOS and Linux.
Binaries are available on Deken or here: https://git.iem.at/pd/vstplugin/releases
BTW, I've made a small tutorial video :
- better error messages when plugins fail to load (e.g. wrong CPU architecture)
- automatically scan VST3 presets
- new simplified preset management system, using named presets which are saved to standard locations (the old methods remain for power users).
vstpluginbrowser.pd: better GUI + plugins can be filtered by keyword, type, category and vendor
[open(can be called asynchronously and responds with
- preset methods can be called asynchronously and respond with messages, e.g.
[reset(can be executed asynchronously and responds with
[search_stop(method to cancel an asynchronous plugin search.
[preset_list(accept an optional plugin key argument
[info(also outputs the VST SDK version.
- experimental support for PDINSTANCE (untested)
- fixed serveral bugs in the VST3 implementation
- fix crash when calling
[midi_*(methods without plugin
- don't lock Pd when receiving events from the GUI thread if DSP is running, instead set an atomic flag and set a clock in the perform routine. This avoids dead-locks in certain plugins and also improves realtime-safety.