thezerobitStarting to swing from #PureData back to #Csound for a large project I'm working on. The #Pd patches get pretty wild pretty quick and while the visual interface is nice to see all the patch cables, it gets exponentially more difficult to wrangle things as the patches grow. I end up spending a lot of time arranging things visually with precision mouse clicks. Csound is plain text code so rearranging it can be done very fast with the keyboard + Vim style model editing.
Pd seems more popular, but I think the systems are generally equivalent with different strengths and weaknesses, and they are open source with active communities, so you can find or build any missing pieces. It remains to be seen if Pd's message system or Csound's k-rate variables are simpler to use for bigger patches.
semitone@thezerobit I have had a similar experience: Started to prototype in Pd and after a while decided that for the final product, it would be easier to move the sound synthesis part to Csound instead of trying to re-implement the stochastic score generation / sequencing in Pd. In my experience, re-arranging in Pd can be painless if I use abstraction (subpatchers) aggressively. Surely, there's no one-size-fits-all solution and both systems have proved useful to me.
Yeah, the more I try to compare and figure out which one is better, I realize that it's going to ultimately be a matter of taste, and I find that, as a programmer by trade, I'm just going to be more adept at wrangling large amounts of code as text.
@thezerobit The programmer side of me sees the interesting features and quirks of Pd's semantics as a fun challenge that warps the mind in a way that a programming language worth learning should. On a more serious note, I like how easy it is to extend Pd by writing some C code to create new objects. Which reminds me that I really should look into pd-lua at some point. And I should finally add some of the features I want to my little Csound score generation library.
@semit0ne
Can confirm that PdLua is nice for non audio rate signals. I would use C for audio rate stuff. Here is a polyphonic voice allocator I wrote in PdLua since I found [poly] to be quite primitive and lacking basic features: https://codeberg.org/thezerobit/0bPureData/src/branch/main/zb_poly.pd_lua
I recently discovered the ELSE library already had an improved voice allocator, but I haven't compared them. I just built the one I wanted to use.
Can confirm that PdLua is nice for non audio rate signals. I would use C for audio rate stuff. Here is a polyphonic voice allocator I wrote in PdLua since I found [poly] to be quite primitive and lacking basic features: https://codeberg.org/thezerobit/0bPureData/src/branch/main/zb_poly.pd_lua
I recently discovered the ELSE library already had an improved voice allocator, but I haven't compared them. I just built the one I wanted to use.
@thezerobit That's really neat. I already some things about Lua that I didn't know (because I never used Lua) from reading your code. Thanks!