plugdata VS avendish

Max4Live is what got me into Ableton, it also got me out of Ableton...

As someone who had been using PureData for quite a while the idea of having that kind of development environment integrated into the DAW was super exciting, unfortunately the actual implementation leaves a lot to be desired; personally the final straw was when I realized that the Max process space was global to Ableton so that global variables would leak between devices (no sandboxing)... This may have been addressed in further releases as I was a very early adopter, but all of the other issues pointed out by the other posters still stand.

If you're looking for a platform agnostic alternative to Max4Live there is PlugData[0] which is a VST implementation of PureData -- the open-source origin of Max and created by the same authors.

And there is the Grid for Bitwig[1] which offers a modular graph based MIDI/DSP programming environment that runs at audio rate and is fully integrated into the DAW as a native solution! The Grid is somewhat limited as it isn't extensible, but it supports >95% of common use cases and is used internally to build Bitwig's native devices. Hopefully in the future Bitwig will extend it's open API surface to include building custom Grid modules -- in the meantime PlugData is perfectly acceptable patch for doing unusual logic calculations and doing left-field things like interfacing with robotics :)

[0] https://plugdata.org/

Automatonism is ongoing, and if you're looking for better UX (as well as a ton of other excellent features, like making plugins and compiling for Daisy) then you should absolutely check out https://plugdata.org!

Sweet! It works now in plugdata, too!

An alternative for this is PlugData -- a native VST host for PureData (the open-source sibling of Max; same original author)

The Rust audio environment might need help, if you're into that:

https://rust.audio/

Maybe this might be worth a look, too:

https://plugdata.org/

It's a recent attempt to make Pure Data more accessible for less technically inclined users.

Well, Miller created Max, which back in those days was more about composition than synthesis and relied on external hardware to create sound. Another fella took Max and developed the commercial product and developed it some more. During this time home computers became good enough for realtime synthesis so Miller developed PD which combined aspects of Max with realtime audio synthesis capabilities. Max thought this was pretty great so integrated pd into Max which gave us Max/MSP, Max is Max Mathews who developed the Music(n) family of programing languages and MSP is Miller S. Puckette.

I would not say that pd or Max/MSP is more approachable, they are pretty even these days unless you stick to vanilla pd with no externals which almost no one does, the main differences is that Max/MSP gives you all you need out of the box but pd can run just about anywhere including in plugins if you are that sort. Max/MSP is considerably more modern in aesthetic but PlugData[0] and PurrData[1] offer more modern interfaces for pd with a few new tricks, PlugData is a plugin version of pd (also standalone), Purrdata is a JavaScript rewrite of the interface with prepackaged externals and solid documentation. And we have a handful of other varieties of pd each which have their own slant and can be found on puredata.info.

0: https://plugdata.org

Not a programmer, but a producer here, and I’m interesting in getting into programming and I don’t know much about it but I want to learn JUCE (and Pure Data; which I know is also available now as a vst! and here’s a link for that https://github.com/plugdata-team/plugdata

This is an important objective of the rapidly-progressing plugdata project! The patcher is based on pure data so you can live patch yourself into deep space with any GP computer (a RasPi works fine), but has a sleek, calm, efficient, and themeable UI. In the last couple of weeks has grown a compiler that is working in its preliminary form both compiling in to C and flashing a Daisy synth dev board. The eventual hope is to gain compatibility across microcontrollers for not just audio synthesis, but for any creative purpose.

The project is here: https://github.com/plugdata-team/plugdata

The builds are coming thick and fast. 0.6.2 is so far behind the daily builds right now that 0.6.3 is going to be an enormous leap in functionality. Tim and the development team are doing a spectacular job of staying focused and cranking out bugfixes and features sometimes multiple times a day.

Happy to introduce you to https://ossia.io there are a lots of tasks open! You can check the projects for the general development axes: https://github.com/ossia/score/projects?query=is%3Aopen ; e.g. Audio, Musicality, Integrations, JACK & Linux integration (some are in Classic projects mode) all have audio-related tasks, some easy, some hard.

Creating new Avendish plug-ins (docs: https://celtera.github.io/avendish/) could also be fairly useful, here's a very basic example one: https://github.com/celtera/avendish/blob/main/examples/Advan...

If you are interested in making max, pd, etc... extension you can look into https://github.com/celtera/avendish : it's made exactly for this and tries to stay very close from standard C++ unlike most existing audio frameworks which often come with their own bespoke standard library reimplementation. The documentation also tries to explain the c++ features it used, you might find this useful!

to automatically generate safe dlopen stubs for runtime dynamic library loading from header files

and through the C++ one (this one is an extremely quick and dirty prototype):

https://github.com/ossia/score/blob/master/src/plugins/score...

to pre-instantiate get(aggregate), for_each(aggregate, f) and other similar functions in https://github.com/celtera/avendish because of how slow it is when done through TMP (doing it that way removed literally dozens of megabytes from my .o and had a positive performance impact even with -O3) ; so I weep a lot when I read that people in the committee object to pack...[indexing]

I really don't know about this, I'm writing audio & media effects in a fairly declarative style with https://github.com/celtera/avendish and I'm so much more productive that it's not even funny - I can rewrite entire effects from scratch in the time that it used to take me to find a bug somewhere

For anyone using c++, my declarative system has some amount of support for clap: https://github.com/celtera/avendish / https://celtera.github.io/avendish/

But unlike clap, targetting this also gives direct access to a few other environments, namely Max, Pd, ossia score, with the list hopefully growing.

Here is an example minimal plugin : https://github.com/celtera/avendish/blob/main/examples/Raw/M...

Note that unlike pretty much every other c/c++ plugin API, the plugin code does not need to include any header, everything is done through reflection of struct members at compile-time.

Here's a per-sample noise generator which uses a small library of pre-made ports: https://github.com/celtera/avendish/blob/main/examples/Helpe...

And a very naive buffer-based audio filter : https://github.com/celtera/avendish/blob/main/examples/Helpe...

UI is supported without relying on a specific UI library, only on a canvas painter concept which can then target Qt, NanoVG, and others to come: https://github.com/celtera/avendish/blob/main/examples/Helpe...

since it binds directly to audio APIs at compile time, it has pretty much zero code size in itself, the smallest plugin it generates for VST2 is around 7kb IIRC

I've ported my lib https://github.com/celtera/avendish to P1061's experimental clang implementation to replace boost.pfr (https://github.com/celtera/avendish/blob/main/include/avnd/common/aggregates.hpp#L67) and it works great, it's only missing pack indexing because right now one still needs to do something like

Working on a sunset of this with https://github.com/celtera/avendish - C++ reflection makes this very easy

so interesting, as a mostly C++ dev, UE's C++ style feels absolutely awful aha. Of course they have to be here because c++ used to not have reflection but I think that nowadays one could use similar principles as the ones I've tried to develop for audio / media objects in https://github.com/celtera/avendish to implement game objects / UObject in a much cleaner way and with better compile times