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

    vstpluginbrowser.jpg

    The new preset browser:

    vstpresetbrowser.jpg

    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!

    Cheers,

    Christof

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

    I’m happy to announce the final release of vstplugin~ v0.2.0 - an external to load VST plugins on Windows, macOS and Linux. Binaries are available on Deken or here: https://git.iem.at/pd/vstplugin/-/releases

    Here's the source code: https://git.iem.at/pd/vstplugin/tree/master

    If possible, please report bugs at https://git.iem.at/pd/vstplugin/issues

    Otherwise just leave them here in the comments.

    Enjoy!


    Changelog

    features

    • VST2 shell plugin support (e.g. "Waves", "Blue Ripple Sound")
    • (experimental) VST3 support including sample accurate automation and auxiliary inputs/outputs for side-chaining
    • soft-bypass
    • potential Cocoa GUI editor for Supercollider
    • faster search/probe (multi-processing)
    • save search/probe results in a cache file to speed up subsequent searches
    • [param_set( and [param_get( now also accept parameter names instead of indices (whitespace is bashed to underscores).
    • set editor window position with [pos( message.

    bug fixes

    • fix broken GUI editor with certain (older) plugins

    changes

    • use CMake for the whole project (not only for the SuperCollider part)
    • removed 'vstsearch' object because of the new cache file system.
    • removed [precision( message (precision can only be set at creation time).

    internal changes

    • use .ini like syntax for plugin info
    • hard-bypass prefers the plugin's bypass method
    • single event loop shared by all plugins

    posted in news read more
  • Spacechild1

    I'm happy to announce the first stable release of vstplugin~, a cross-platform Pd external for using VST plugins in Pd.
    Binaries are already available on Deken.

    The repository also includes a version for Supercollider called VSTPlugin (which works very differently but achieves the same thing).

    The overall design and functionality of vstplugin~ v0.1.0 is the same as in vstplugin~ v0.1-alpha, but there are some breaking changes and new features! Have a look at the change log in https://git.iem.at/pd/vstplugin/releases

    Source code: https://git.iem.at/pd/vstplugin/tree/master

    Features:

    • use any VST plugin (audio effect, MIDI effect, soft synth etc.)
    • search and probe plugins in the standard VST directories or in user defined paths
    • automate plugin parameters programmatically
    • use either the native VST GUI (WIN32, Cocoa, X11) or a generic editor
      (NOTE: the VST GUI doesn't work [yet] for SuperCollider on macOS)
    • preset management: read/write standard .fxp and .fxb files or
      set/get the plugin state as raw data to build your own preset management
    • MIDI input/output
    • basic sequencing support (for arpeggiators, sequencers etc.)

    NOTE: currently only VST2.x plugins are supported but VST3 support will come soon!
    64bit VST plugins can only be loaded with the 64bit version of [vstplugin~] / VSTPlugin.scx and vice versa.

    See the help files (vstplugin~-help.pd and VSTPlugin.schelp) for detailed instructions.

    If possible, please report any issues or feature requests to https://git.iem.at/pd/vstplugin/issues

    Have fun!

    posted in news read more
  • Spacechild1

    Generally, the "blocksize" in the audio setting really is the hardware buffer size and not Pd's global blocksize (which is always 64 samples).

    Modern ASIO drivers are multiclient which means that the device can be used by more than one app at the same time. When you set the buffer size in your device app (e.g. Focusrite MixControl) this will set the internal blocksize and consequently the minimum latency possible for all clients. Usually you would want to set the internal buffer size as low as possible (without getting audio glitches).

    Individiual clients (e.g. a Pd instance) can request a buffer size from the device. This can't be smaller than the above mentioned internal buffer size, but it can be larger (if you need extra latency). Most DAWs control the latency via the buffer size while Pd has it's own buffering mechanism ("delay").

    Note that for Pd the hardware buffer size affects the overall timing resolution (when DSP is on). Pd will calculate several blocks of 64 samples as fast as possible until it has enough samples to send to the device. If the hardware buffer size is 256, Pd will calculate 4 blocks in a row (4 * 64 = 256) and then wait until the device asks for another 256 samples. This causes jitter! (Try [bang~] with [realtime] and [print] to see it yourself). The lower the hardware buffer size, the less jitter you get, so generally it's better to keep "blocksize" as low as possible and rather increase "delay" if you need more latency.

    BTW, in case of old single client ASIO drivers, "blocksize" would directly set the hardware buffer size of the device. This is still the case e.g. with ASIO4ALL.

    posted in technical issues read more
  • Spacechild1

    Put in a formal way, it means that computation time equals O(n).
    --> https://en.wikipedia.org/wiki/Time_complexity#Table_of_common_time_complexities
    I give you a simple example regarding [list-split]: Let's suppose dripping 100 elements would take 0.01 ms, then dripping 1000 elements will take 0.1 ms; 10.000 elements will take 1 ms etc.

    I think the algorithm of [list-drip] itself should be actually O(log(n)) but in Pd you'll end up with O(n). At least this is what I've measured... Please anyone correct me if I'm wrong

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!