For those who are interested in music programming, I would like to invite you to have a look on the project I am working on and any feedback would be appreciated.
Pd is one of the most famous MPL and I have been referring to and reflecting on its design from the first day I design Glicol. I have been teaching it to students, and one issue I found is that when the projects get a little complex, the code becomes very difficult to read even with comments. Essentially I think it's determined by the philosophy of the language. So I wouldn't complain about the fact that you need to start from scratch. That's exactly the elegancy from pd. Have a look on the "counter" example in Pd; it will give you a new understanding for "programming".
But from this perspective, I would be interested to see how people will design VST with PD from scratch. Maybe the opposite would be more practical, to use VST in PD (https://youtu.be/Cs0NPime0kU), considering they are both GUI-based tools. PD is also great for algorithmic composition (https://youtu.be/I9_3CfRm8GE).
Also to make project in real world some batteries like the else lib would be great and it's great that the PlugData has included that. Also check this Erbe reverb pd patches:
http://tre.ucsd.edu/wordpress/?p=625
You should also look at some hardware in the future such as Bela and Daisy where you can also run Pd and Glicol.
I would love to get into this, but its syntax is so hard to read
I get that you went for a compact syntax that is fast to write (maybe like a shell scripting for music programming), but it's also too hard to read / too sigil heavy IMO
In special, the use of ` is very confusing and could probably be replaced by braces { }
Thanks for your feedback. The code on the front page is just to show everything in one place. Admittedly, rhe Meta node may be too advanced to be there. But I guess if you check the demo page you will find most syntax fairly intuitive.
For those who don't know, Pure Data or PD is a visual audio programming language that can be used to develop software synthesizers. It's open source, the commercial version by the same creator is called MAX-MSP.
To be honest, I've spent many hours in PD and Max and didn't realize that Miller Puckette was behind both. Super cool!
Next week, I travel to Bali to focus on developing a data flow based visual music synth. I can't understate how big an influence that Puckette's work has been on my thinking.
Pukette got the shits with the conditions of his grant from the french government that allowed the development of Max, because it disallowed him to use the same techniques to do visual synthesis. So he quit and reimplemented the whole thing. Except this time he used an open source license.
The other advantage is because these things were implemented in the 80s when real time audio was a really big ask for computers, they are very computationally efficient.
> The other advantage is because these things were implemented in the 80s
Pd was developed in the mid 90s
> they are very computationally efficient
Not as efficient as it could be, though. For example, instead of proper SIMD instructions, the DSP perform routines only use manual loop unrolling, praying that the compiler will auto-vectorize it.
No, I don't think that Rust would buy us anything in this regard.
"Async" in languages like Rust are meant for an entire different problem domain (mostly networking).
In my post above I'm talking about dispatching commands from the audio thread to a helper thread (pool) - and back. This has to be done in a realtime safe manner, so a general async framework won't be appropriate.
> There are some good gui tools in Rust as well:
I don't think GUI programming is exactly one of Rust's strengths :-)
(BTW, I did not downvote your comment. I know that you have actually written audio code in Rust and therefore assumed it was an honest question from your side :-)
Tangential, but I was surprised at how clean the project structure is, considering that the last time I used JUCE, it imposed a messy and annoying (IMO) project structure based on its own build tool. Turns out I missed the news from a couple of years ago, and you can now use CMake and include JUCE in a project as a "library" rather than an all-encompassing "framework": https://forum.juce.com/t/native-built-in-cmake-support-in-ju...
With that said, my Pure Data is very rusty but this seems like a great excuse to get back into it.
If you ever need to use Pure Data patches in Android combined with sensors, networking, and more you can use PHONK. There is an example where you just drop a patch inside and you can communicate with it using the typical send/receives
I am only on mobile right now and travelling so can’t actually test this. But boy is it exciting to see a potential OSS alternative to max4live.
I think Max and m4l are well worth the price if it’s something you do all the time, but as a more casual user something with a lower cost of entry would be highly welcomed.
This is not an alternative to Max4Live. M4L's integration with Live goes way beyond what any JUCE-based plugin is going to be able to do.
This will be handy for some things that overlap with what M4L can do. But there's lots of things people do with M4L in Ableton Live that you will not be able to do with PlugData in any plugin host.
I have a large collection audio plug-ins, but mainly for effects. While I would assume Pure Data can do effects I haven’t seen that capability pushed. So, does anyone know of good resources for learning Pure Data, not just in the context of effects, but for creating synths or anything else as well?
Genuinely just google whatever effect you want with “pure data”. E.g. “delay patch pure data” and you’ll find lots and lots of resources. If you want something deeper look for more generalized DSP tutorials in PD
I know there are a lot lisp fans here, so at the risk of being a thread-spammer: I made an extension for Pure Data to let you program in Pd in Scheme (the message part, not the DSP part).
I'm going to ask the dumb question here - how is this at the top with zero discussion? If I need to get dunked for asking that's fine, but I don't understand, since HackerNews is suppose to be a place for high quality discussion on tech.
It often takes a while for comments to start showing up. That can be a good sign, actually—interesting reactions often take a while, since processing information takes time. Quick reflexive responses are often a bit mechanical/predictable.
This plugin could potentially be a big deal. PureData has been around for decades but fell behind Max and/or MaxMSP mostly (IMO) due to usability limitations. If more people will be able to incorporate PureData organically into their workflow, it could create a real alternative to Max4Live in DAWs other than Live.
I could fantasize even further. A PureData plug-in could kickstart a VCVRack type effort - an open source library of interconnected audio processing modules.
The advantage of this PureData plugin and Max4Live over VCVRack is that you can edit the patch on the fly right in the DAW (in addition to the fact that visual programming is way more accessible than a compiled language).
Yes. There os also a commercial initiative by the author of VCV to have it as a VST im the DAW. The difference between the two are that Cardinal only accepts open source modules and is packaged with all of them, while the VCV official VST lets you download modules on the fly.
The fact that it's paid might be a turn off for some, but I've found it to be really useful, and it works really well inside of Ableton. Can't speak for other DAWs but having been using it for the past 6 months or so, it's been fantastic.
Does anyone know of good resources for folks who want to develop their own modules for VCV rack?
This is cool, but I think we are talking about different things. From reading the description of this project it looks like you can't actually _edit_ the individual modules. They still require compilation since it's C++. You can change the patch by adding modules and tweaking them a-la hardware Eurorack.
M4L and PD allow you to open the patch ("patch" as in MaxMSP patch, not a Eurorack patch) and edit its source code. Which is a completely different level of sound manipulation and synthesis.
It's all about the level you want to edit the patch at. With PD you are likely to generally work at a lower level than in Rack/Cardinal, but you're still patching together elements of varying complexity.
You can also run PD as a plugin inside Rack to get "the best of both worlds".
I had a look at automationism, but don't really like how it imposes the CV concept in an environment where it doesn't make much sense (to me) - but is still fun to fiddle with. I came across a toolkit[1] yesterday which is similar but doesn't impose analogue concepts on the workflow in the same manner. Also not as polished in the GUI sense either mind you, but the guy who wrote it makes really good occasional pd tutorials on youtube as well[2]
This is cool if you are interested in digital synthesis. Pure data and max/ msp have a long and complicated history. Very nice to see that pure data is still keeping up vs the ableton live / max programs.
PD is pretty popular and also has the distinction of being first-of-its-kind in many respects, so a major UX overhaul would automatically attract approval. Also the front page on HN is a lot less 'competitive' on the weekends.
Good q! I’m an audio dev who thought the general community might appreciate the project. It’s a cool effort (my primary beef with pd was always the UI)
PureData is an interesting tool, but it is very low-level. You have to reimplement from scratch things that are present in most DAWs or synths, for example: there is no GUI-controlled equaliser, no reverb. No oscilloscopes and FFT displays.
If I am not mistaken, there is even no primitive for modulating frequency of one oscillator with another.
The filters are very primitive and limited. The user is expected to learn the theory themselves. As far as I remember, there is no filter that can be modulated with audio frequency (without artifacts) and it is difficult to find information how to create one. Does anybody know how to do it, by chance?
The idea of Pure Data is to be a minimum core that can be extended with "abstractions" and "externals". For example, the "else" library comes with literally hundreds of additional useful objects. Everything you wish for in your post already exists, you just need to find it :-p
From tcl/tk to juce - there is a lot to be said about that. Taking in all the FUDI commands from pdsend, and then translating it into a Juce GUI is pretty, and pretty neat. Especially if you can organize the patch cords. You may start a fight, with that in mind.
This is more or less what purr-data does (but then it's tcl to JS), but PlugData works differently. Basically, it assumes that patches only change through user interaction. Since all user interaction goes through PlugData's GUI, it can check and synchronise the patch content with Pd whenever the user does something. I do intercept messages to UI objects, to detect when their state has changed.
The big advantage of that is that we can change the way the UI looks without modifying any Pd source code. PlugData actually works on top of an unmodified pd-vanilla, which saves me a lot of maintenance work.
The only limitation with this is that dynamic patching (using messages to pd to modify the patch, like a meta-patch) doesn't work yet.
PureData has a very outdated looking GUI. Actually, it even looks as if the elements are rendered wrong. This has always driven me away from using it. This new thing has a much more pleasant looking GUI. Promising.
My issue with the PureData UI was that it was a RSI factory. Constantly having to precisely mouse-drag connections between the teeny-tiny ports on the objects:
FWIW, there is a current effort of rewriting the GUI backend to move away from Tcl/Tk and allowing alternative GUI implementations. It will take some time though.
Personally, my main problem with the current Tcl/Tk GUI is that it's also painfully slow...
https://glicol.org
You can also live coding Glicol code as scripts inside a VST plugin:
https://youtu.be/tmmBhBmIEW0
Pd is one of the most famous MPL and I have been referring to and reflecting on its design from the first day I design Glicol. I have been teaching it to students, and one issue I found is that when the projects get a little complex, the code becomes very difficult to read even with comments. Essentially I think it's determined by the philosophy of the language. So I wouldn't complain about the fact that you need to start from scratch. That's exactly the elegancy from pd. Have a look on the "counter" example in Pd; it will give you a new understanding for "programming".
But from this perspective, I would be interested to see how people will design VST with PD from scratch. Maybe the opposite would be more practical, to use VST in PD (https://youtu.be/Cs0NPime0kU), considering they are both GUI-based tools. PD is also great for algorithmic composition (https://youtu.be/I9_3CfRm8GE).
Also to make project in real world some batteries like the else lib would be great and it's great that the PlugData has included that. Also check this Erbe reverb pd patches: http://tre.ucsd.edu/wordpress/?p=625
You should also look at some hardware in the future such as Bela and Daisy where you can also run Pd and Glicol.