• Spacechild1

    You can use the Jack ASIO driver.

    posted in technical issues read more
  • Spacechild1

    Like iemlib's [iem_receive] or iemgut's [oreceive] ;-)?

    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.

    posted in abstract~ read more
  • Spacechild1

    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?


    posted in technical issues read more
  • Spacechild1

    Generally: if you encounter issues with Pd, don't just complain on the forum (which only few Pd devs read), but rather file an issue on GitHub!

    posted in technical issues read more
  • Spacechild1


    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!


    posted in technical issues read more
  • Spacechild1

    Finally, Pd 0.51-1 now has a fast-forward message, which allows batch processing while in interactive mode.

    It works similar to my [batchrecord] external.

    posted in technical issues read more
  • Spacechild1

    -batch means "run Pd as fast as possible". This is similar to NRT mode in SuperCollider.

    -nrt means "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).

    So -batch and -nrt are really not related.

    posted in technical issues read more
  • Spacechild1

    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_save( + [preset_load( instead, because it allows to load/save presets programmatically via Pd messages and it's the same for all plugins.

    posted in technical issues read more
  • Spacechild1

    BTW, you can use [preset_list( to output all user presets for the given plugin. program_list only lists built-in factory presets

    posted in technical issues read more
  • Spacechild1

    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_save foo( and [preset_load foo(. They will automatically show up in [vstpresetbrowser].

    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).

    posted in technical issues read more
  • Spacechild1

    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.

    posted in news read more
  • Spacechild1


    CMake can generate Visual Studio solutions.

    posted in extra~ read more
  • Spacechild1

    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.

    Have fun!


    posted in news read more
  • Spacechild1

    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.


    bug fixes

    • 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

    posted in news read more
  • Spacechild1

    Thanks for your reply! Clever stuff, I definitely want to study it when I have a bit more time.

    posted in news read more
  • Spacechild1

    The DSP is multi-threaded. It is supposed to be wait-free.

    @Nicolas-Danet This sounds exciting! I have some questions:

    1. how do you handle concurrent garray reads/writes?
    2. how do you handle concurrent access to the clock list (e.g. calling clock_set in the perform routine)?
    3. 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 ;-)

    Cheers, Christof

    posted in news read more
  • Spacechild1

    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. -eventloop / -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 :-p

    posted in news read more
  • Spacechild1

    The improved plugin browser:


    The new preset browser:


    posted in news read more
  • Spacechild1

    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

    Please report any issues at https://git.iem.at/pd/vstplugin/issues or https://github.com/Spacechild1/vstplugin/issues

    BTW, I've made a small tutorial video :-):

    Change Log

    New features:

    • 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).
    • new vstpresetbrowser.pd abstraction
    • improved vstpluginbrowser.pd: better GUI + plugins can be filtered by keyword, type, category and vendor
    • [open( can be called asynchronously and responds with [open <success>(
    • preset methods can be called asynchronously and respond with messages, e.g. [preset_load <success>(
    • [reset( can be executed asynchronously and responds with [reset(.
    • [search_stop( method to cancel an asynchronous plugin search.
    • [param_list(, [program_list( and [preset_list( accept an optional plugin key argument
    • [info( also outputs the VST SDK version.
    • experimental support for PDINSTANCE (untested)

    Bug fixes:

    • 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.

    Have fun!



    posted in news read more
  • Spacechild1

    @boonier Can you do [search_clear 1( + [search -a( and post the Pd console output? Can you send me one of your (free) plugins?

    posted in news read more
Internal error.

Oops! Looks like something went wrong!