Note the following caveat with settable receives: https://github.com/pure-data/pure-data/pull/604#issuecomment-487890771
TL;DR: settable receives work fine most of time, but under specific circumstances they can crash Pd. Use with care.
I know that using send~ and receive~ introduce latency
Not necessarily. You can in fact force the receive~ to be scheduled after the send~, in which case there is no latency, just like with delwrite~ and delread~.
and am wondering whether using subpatches via inlet~ and outlet~ also introduce latency.
No, unless the inner patch has a bigger blocksize than the outer patch. In that case, the latency is the difference between the two block sizes.
Does send (without tilde) introduce any latency?
"latency" doesn't exist in the message domain. When you send a message to [send], it is delivered instantly to all receivers. There is no semantic difference between using [send] or patch cords.
Does using subpatches rather than one big page introduce latency?
How exactly is one supposed to keep up to date on new features?
Read the release notes: http://msp.ucsd.edu/Pd_documentation/x5.htm#s1
The changelog is 12 years out of date.
Good catch. This needs to be fixed. Also, the change log should reside in the toplevel directory and not buried in the "src" folder. I'll make a PR on GitHub.
Usually, features can be discovered by browsing the help files. The problem in this case is that there's no real help file for "pd" messages. This needs to be done.
Anyway, "fast-forward" is a very useful feature. Before I've made an external called
[batchrecord~]which achieved the same thing. I don't know if Miller became aware of it, or if it was just a coincidence. Either way, I think it's great that it's now part of Pd vanilla!
-batchmeans "run Pd as fast as possible". This is similar to NRT mode in SuperCollider.
-nrtmeans "run Pd without realtime priority". Usually, you would only use that for debugging (especially on Linux, to disable the watchdog). Otherwise, it has only downsides (e.g. higher risk of audio dropouts).
-nrtare really not related.
The whole situation is complicated by the fact that many plugins have their own preset management, which is often only accessible via the plugin GUI.
I would suggest to always use
[preset_load(instead, because it allows to load/save presets programmatically via Pd messages and it's the same for all plugins.
Hey, sorry for being late to the party. Maybe the next time just ping me
The "programs" in the cache file are really just (read-only) factory presets. You can choose them with "program_set".
What you're looking for are the "preset" methods, i.e. "preset_save" and "preset_load". Those are for storing and recalling user presets. The presets are saved in standardized locations, so you can simply do
[preset_load foo(. They will automatically show up in
The "program_read" and "program_write" methods are more low-level and allow to save/read presets using custom file paths.
Finally, there's "program_data_set" and "program_data_get", which lets you work with the raw plugin state as a list of bytes, e.g. to build your own preset management.
Actually, the section
[pd presets]in the help file mentions "preset_save" and "preset_load" first, so I'm surprised you didn't consider them. Maybe you still have an older version? The documentation has certainly improved (but it is still far from perfect).
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.