(untitled)

Audio Programming MEGATHREAD! Hi fellas. Let's talk real(time) soykaf. Let's share your questions, accomplishments, tutorials and papers. I am a total newbie in this area, but very excited one. My first question: What framework would you recommend for someone who would like to create VST for DAWs? I've tried IPlug2 today, it looks ok and has huge potential, but I am afraid that is's still too much "in development". For example out of 2 examples I tried on my Windows 10 one didn't worked and second work only as a standalone target. Building VST2/3 projects result in errors. Also, I would prefer developing on Linux. I have tried JUCE some time ago, but I really didn't liked that's such a huge tool. Maybe I should give it more time. Also, is there a chance to use only: 1. imgui (or other GUI library, imgui would be cool as it's 3D-pipeline agnostic, so probably good for plugins). 2. some DSP library 3. some MIDI library 4. probably some other libraries which I don't know about yet This would be better than using huge undocumented frameworks, I can sacrifice all this nice looking knobs.

>>16099 Ok, I think I will study https://github.com/amsynth then I will look for some windows equivalent and finally I will be able to create simple multi platform VST & standalone synth without bloat frameworks Also, could someone give me some good materials about MIDI protocol? Thanks!

>>16099 One more edit: I am currently building on Linux https://github.com/steinbergmedia/vst3sdk This look super cool, Idk why haven't I found this earlier.

>>16101 Ok, after ~10h spent trying everything but JUCE I decided to give it a try. It rocks guys. If anyone here would ever start his journey with audio plugins development then give it a try!

>>16127 thanks for the advice

Has anyone used Supercollider here? I was thinking about getting into it, wondering if someone has pro-tips (I'm already pretty good at doing stuff with a regular DAW and have used pure data a little).

With the supercollider thread about to die. I think this thread should be the one getting the posts. >>16567 Here is a really neat playlist that introduces supercollider from the ground up. Hope you (and anybody else) finds it interesting https://www.youtube.com/watch?v=yRzsOOiJ_p4&list=PLPYzvS8A_rTaNDweXe6PX4CXSGq4iEWYC

What are your favourite audio-related programming languages? I mostly use Tidalcycles(Haskell) and FAUST, but am too much of a fool to get into DSP

I've been trying to learn supercollider for a while but for whatever reason I've had a lot of trouble wrapping my head around it. It just doesn't feel as flexible as just doing stuff in a conventional programming language, but on the other hand the standard library lacks the high level functionality you'd expect from a simple embedded scripting language. To me the experience feels like building a puredata node graph with an annoying text interface, so I tend to just use puredata instead since the feature set is pretty similar. I'll have to check out tidalcycles since I do like Haskell.

>>21168 FAUST might suit you, but it's a pain to find decent documentation. The Kadenze course is probably the only beginner friendly tutorial https://faustide.grame.fr/ I like PD, but having to drag your mouse gets annoying fast

>>21170 >I like PD, but having to drag your mouse gets annoying fast I agree, but I have yet to find a code-based metaphor that works better than a visual node graph for patching continuous signals around on the fly. Some of the problem is the fundamental disconnect between how "patch cables" are represented in the language and how your computer actually processes audio (using ring buffers and such). In SC's case they get around it by essentially using the language to construct a node graph which is passed to the synth server for processing. It's a lot like writing shaders, actually. The problem is just that if you want to dig down and actually do stuff with buffers and byte streams you have to write a plugin for the sc server itself (in another language) which can't be done live, and is somewhat impractical to do if you just want to explore an idea.

>>21167 >but am too much of a fool to get into DSP Are you having trouble with the math, or the coding? >>21170 >FAUST might suit you Looks pretty nice, and actively developed.

>>21170 >>21297 I am so glad you recommended faust. I just spent all day messing around with it, and I love it. It's a really well designed language, and I like that it just compiles to C++ (those build plugin things it ships with are incredible). Now I'm just looking for a good option for live coding/sequencing. Writing soft synths in faust and controlling them with something else seems like a great workflow.

>>21297 >Are you having trouble with the math, or the coding? The math. I have worked through Andy Farnell's Designing Sound for a while, but I can't get any further than his examples. Do you know some good resources to learn DSP from the beginning? Julius O Smith's books look good, but they're too hard atm >>21329 That's great to hear You could try exporting your faust synths to supercollider and then use Tidal Cycles for live coding. Tidal can be used with any SC Synthdef

I heard cabbage

>>16567 I think there's only this youtube tutorial series that I was able to find, seems like SC knowledge is extremely well kept https://www.youtube.com/watch?v=ntL8QDOhhL8 also I'd recommend checking out this, although it's more live coding focused he does go quite deep into what things are useful/how to do soykaf in SuperCollider. https://github.com/theseanco/howto_co34pt_liveCode

>>21167 My favourite music language is volsung https://landahl.tech/volsung/ It is terrible, I made it in university.

I completely misunderstood what an audio programming language was. I truly believed programmers were odd enough to find some kind of way to write programs by using audio. Like, with synths or something, they write software. I always avoided the topic based off of that erroneous presumption as I thought "audio programming" would ultimately prove to just be a weird some fringe collective of programmers engage in, like writing obfuscated C or something. This is actually pretty interesting. I think I want to get into this.

>>21385 what you described sounds about 1000x more interesting than heavily getting into calculus and fourier analysis someone do it pls

>>21352 comfy

I'll leave this right here. https://ourmachinery.com/post/writing-a-low-level-sound-system/

>>21385 This is actually kind of what analog computers used to be. Not audio per se but analog signal processing. You can solve differential equations by operating on signals with analog circuitry. They don't get used much any more but they do offer an elegant way to solve certain classes of problem that digital computers would brute force with approximation methods. >>21387 >1000x more interesting than heavily getting into calculus and fourier analysis DSP is pretty interesting in its own right. Your sound card is the most versatile synthesizer out there, and learning how to use it is a lot of fun if you're into that kind of thing. Anyone who likes modular synths or freaky guitar pedal setups should give audio programming a try. >>21329 Update on this: I've been working on cloning the Loquelic Iteritas dual oscillator in Faust based on the manual from NE's website https://www.noiseengineering.us/alphabetical . I've got all the basic functionality finished and just need to create a better UI and do some minor refactoring. I don't actually own a loquelic to directly compare but to my ears it sounds reasonably close to the original. I'll try to remember to post my source when I'm done. Does anyone else have projects to share? Since these languages are so niche it's hard to find good examples. Would be nice to see what others have come up with.

>>21562 >You can solve differential equations by operating on signals with analog circuitry hmm, any diff eq or just a restricted class?

>>21563 I think mostly the type you usually use Fourier analysis to solve. This isn't really my area of expertise though. This isn't the same thing, but I know you can also use analog circuitry to find attractors in certain parameterized systems. For example, you can render a Lorenz attractor with an oscilloscope and some basic circuit components.

Where should someone who knows nothing of audio programming begin? Assuming a strong mathematical background

>>21576 Depends, what do you want to do with it? Are you more interested in the live coding music sequencing side of it, or are you more into DSP and writing cool synths? Somewhere in between? Speaking from experience, having a strong math background will make all of this considerably easier. If you don't already know how various synths work, I'd recommend starting there. Since you know math you'll be able to understand the key principles just from glancing over Wikipedia articles or whatever, but don't leave it at that. Actually implement them in code, and importantly: listen to them! Knowing what wave folding *is* doesn't tell you how to use it creatively. One tricky thing about all this is it exists at an intersection of analog circuit theory, computer science mathematics, music theory, acoustics, audio engineering, and synth nerd soykaf. So the jargon is quite eclectic.

>>21578 Not them, but what are some good resources if you're a musician/programmer with high school tier math knowledge?

>>21634 I don't know if I can recommend any intro material because I learned this stuff from soykafty mcgraw hill textbooks and then never really needed to go back and re-learn it. I can give you some key words to look up though. When you say "high school tier" do you mean calculus, or just algebra? The main thing is being comfortable working with functions (math functions, not programming functions), and reading mathematical notation, because if you look up "how does phase modulation work?" you're going to get an answer like "sin(u*t + a*sin(v*t))". If you can look at that and tell me what it's actually doing as t varies over time (for instance, what do the a, u and v parameters represent?) then you've got enough math to start writing basic oscillators. You can get pretty far just playing with oscillators. Most modulation-type effects are achievable at this point. Amplitude modulation, frequency modulation, phase modulation, vibrato, flangers, ring mods, etc. It's mostly just adding, multiplying, and composing sinusoids. Throw in ramps/saws and square waves and you get pulse width modulation, triggers, envelopes and all that synthy soykaf. Compression and distortion is easy. You get a sample, pass it through a nonlinear function, and write it out. Filters are more complicated, and require actual calculus to understand. You can just look up "low pass filter" and copy whatever formula you get, but it will be difficult for you to modify it, or understand what different parameters do if you don't know calc. Really most of this stuff is grounded in fourier analysis, which seems really difficult at first, and it sort of is, but if you can wrap your head around the weird notation (infinite sums of functions and all that) you'll at least be able to use it even if you don't fully understand what's going on. Then there's the physical modelling stuff. This is the part where you need real math. Differential equations mostly. Numerical analysis is useful too. If you want reverb that doesn't sound like soykaf, or you want to make something that sounds like a stringed instrument, or you want to clone analog gear, this is kind of where you're at. Frankly most of this stuff is fiddly and boring IMO. Finally, there's the more experimental side of things, by which I mean "doing weird soykaf with samples rather than gluing sine waves together", also known as "stuff that wasn't invented in the 40s". It turns out that computer audio is actually a sequence of bytes and you don't have to pretend it's a continuous voltage coming in on a copper wire. Your sound card is in itself an extremely versatile synthesizer! There are a lot of neat implications here, but I'll just recommend looking up granular synthesis and leave it at that, because this post is already too long.

Can anyone instruct me these things, I am a curious guy passing over here, and I am of course a Programmer(if I wasn't I would not even look at this thread), but audio programming is new to me, can someone tell me what is that, and for what do we use it, and where can I learn it(please no simple basic tutorials, that repeat the same things over and over again, and I prefer it to be raging from beginner level in the very first beginning obviously to the master level in the very end, I want to know how far I could Get there)

>>21642 >what is that This thread is about programming languages which are designed specifically to manipulate audio streams. The point of using them, rather than just using a general purpose language, is that writing software that deals with audio requires a lot of annoying fiddly boilerplate. You don't have "wires" and "jacks" like with hardware, so you have to set up a lot of read/write ring buffers. This is difficult because you want to parallelize it (because you need to be able to process 20k+ samples per second through the whole pipeline) but at the same time there is a strict temporal dependency, so there's a ton of careful coordination between threads. Most audio programming languages are functional, and so you can express DSP algorithms as a function of signals rather than as a sequence of operations on memory objects. In a more general sense, audio programming can be synonymous with digital signal processing, but we're talking about a specific subset of that. >for what do we use it Mostly for developing tools for musical composition and production. Different languages have different specific focuses. Faust, for instance, is great for writing plugins or standalone audio effects that can be used with a DAW or other music production tools. Supercollider, tidal cycles, puredate (a visual programming language), sonic pi, and the like are intended to be used "live", as a sort of text-based sequencer/synth hybrid. >where can I learn it Just pick a language with good documentation and read it. Most will have some examples that will get you up and running. This part will be easy for you since you are already a programmer. If you don't know anything about synthesis or audio processing in an abstract sense, see >>21636 . You can get started with high school level mathematics (in America, the relevant courses are usually called "precalculus" or "algebra II", and "trigonometry").

>>21636 Okay this is really cool, I am keen of mathematics, I am still a high schooler, but I made some self schooling during my career as a part time programmer, and Fourrier analysis is a fun to me, I really enjoy it, and I am already familiar with sinusoids mathematical notation from my physics classes and other lessons I took myself, you mentioned some textbooks, that you started with right! Can you please send me some free e-copies, so I can read them and see if I am able to start audio programming? (hope you are not against free ebooks, especially if they are licensed and normally protected by pay walls, assuming that people in programming and scientific chans are more into open-education out of fees, and freedom of knowledge)

>>21662 Oh I would never recommend the textbooks I learned calc from. They were garbage that my high school forced on us. That's why I don't really have any specific recs for beginner stuff. Also, I've never actually studied DSP out of a book; it's just that I approached it after I already knew the math from other courses, so I could just pick up the details from Wikipedia articles at first and engineering papers later. I probably have some textbooks for Fourier analysis and linear algebra though. Introductory linear algebra isn't too relevant to DSP but once you get into abstract vector spaces of functions it's pretty important. Let me think about it and get back to you. Also, library genesis is an excellent source for pirated STEM textbooks: https://gen.lib.rus.ec

>>21664 OMG, you know libgen, oh my god, It has been four years I am using that site and I think it's creator (Alexandra El Bakyan) is a true legend that should be classified with those who changed humanity, Anyway. My problem is not with calculus and Fourrier Analysis, I really want to Lear audio programming, and I think I have the necessary math skills to be to understand it, just let me know, if you have any textbooks, documentations, videos, courses(okay you said you have none). Documentations are enough, and even if they are not basic beginner staff, I will try my best to understand it anyway

>>21671 >

>>21671 >want to Lear audio programming, and I think I have the necessary math skills to be to understand it Oh in that case just pick a language and read the docs. Read some wikipedia articles on synths if you want some more info about how specific processing algorithms or effects work. There's something to be said for learning theory, but you already have that. Just practice applying it.

>>21167 Sonic Pi is pretty impressive. The author even uses it to create music live on stage.

>>21830 aaron is a dumb ass nerd who gets off being a 'le hacker' look at this punk

>>21167 I use Python with rtmidi to write an automatic composer / sequencer. I tried tidalcycles (I like Haskell so had my hopes high) and some other environments but found them very unsatisfactory. Maybe I'll try Faust for the lower level stuff though...

>>21834 >shirt says "programmer" Lel

>>21834 lol a lot of people into live coding and generative music are like this for whatever reason. I assume it's because they're surrounded by artsy music school types that think they're tech gods because they know how to program (this is, I assume, how he was convinced that a "programmer" t shirt is not unmitigated cringe). the rest are demoscene types or hard core experimental music theory nerds, which are both usually pretty cool. bit of a tangent, but I'm very conflicted about live coders projecting their text editor on a screen behind them. on one hand it's kind of nice to see what they're doing, and I kind of wish people who play synth/laptop sets did a similar thing with a webcam or screen recording of their DAW, but on the other hand it certainly adds to the impression that live coding is more of a gimmick than a substantially different way to approach composition with tangible benefits over e.g. a tracker. I don't necessarily believe this but most of the actual music that live coders produce doesn't help me argue otherwise.

Anyone else using FPGA for a synthesizer? Right now I just have a resistor ladder for my DAC, I'm thinking about upgrading it, but I'm not sure what to replace it with. Any recommendations? >>21844 Live coded music is a meme. It's almost always just techno which would have been much more easily created by a normal sequencer. You can make interesting procedural soundscapes, but there's too much tweaking to get them right for on the spot composition. I think live coders should stick to graphics with fragment shaders. That's the sweet spot of instant gratification and interesting choices.

>>21846 >It's almost always just techno which would have been much more easily created by a normal sequencer. This is a fair characterization of what's out there, but I don't think it's the result of anything intrinsic to live coding. The problem as I see it is that live coders lose sight of the musical purpose of what they're doing and instead fixate on the act of coding itself (which is exemplified by the tendency to make the text editor part of the performance). It's interesting to compare live coders to people who perform using modular synths. They have similar advantages and disadvantages compared to conventional DAW/trackers or standalone hardware synths, respectively. Like live coding, patching a modular synth is kind of difficult to do live, and tends to be more cerebral than intuitive, but if you can manage it, it opens up rich potential for genuine musical improvisation that just doesn't exist if you're just pressing play on some midi tracks and twisting some knobs like a glorified DJ. For whatever reason, live coders haven't managed to realize this potential. The cynic in me would also suggest that since live coding is still niche and eccentric, it is easier for people to break into it and become popular within that niche without much musical vision. The art and music world is full of tech cargo cultists: the kind of person whose website biography starts with "my work exists on the intersection of art and technology...". They are considered, and consider themselves, cutting edge purely by virtue of the fact that they are using a computer to do something more technically advanced than running ableton. How to fix it? First of all, the dogma around starting from a blank text editor and doing your whole set with just that one piece of software has to go. Wasting time writing boilerplate only means you have less time for more interesting things. Use coding to do what it's good at: constructing deep, expressive automation pipelines which can dynamically vary a ton of different parameters in response to a single input or control. If your music doesn't require a sequencer, maybe you're doing something more ambient or experimental, then don't use one. But if you're using code to generate 16 step syncopated drum patterns... just use a fuarrrking sequencer. Hell, write your own damn sequencer if you want the hacker cred. Same goes for synths. Nobody gives a fuarrrk if you can bash out an FM oscillator on the fly. If that's all you're doing, write it beforehand and control it with a sequencer or code. The only code you write live should be code you want to be able to change live. Ironically, I think a lot of live coders tend to neglect non-live coding in their work. As in, writing their own soykaf. The main advantage of live coding over twiddling virtual knobs in ableton is that you can break the operations and effects you'd otherwise use some VST for into small modular chunks and compose them in any way you want. Writing these modular chunks is easy. You don't even need to use a "audio programming" language to do it. Just code them up in C++ or whatever and make sure you give them an interface into whatever live coding environment you want to use (or even just a generic OSC or MIDI interface). The ease of developing your own custom synthesizer building blocks (compared to hardware where you have to solder together actual circuit components, or VSTs where you have to comply with a fiddly and limited standard) is a massive underutilized advantage of live coding.

>>21844 completely agreed - I have nothing but respect for both demo and NIME people live coding does usually seem quite gimmicky although I would say some of the software does provide a lot of advantages when it comes to strictly making music (not necessarily on stage). that apart, it has one feature thats crucial: it's drastically different from your usual DAW, it takes a serious amount of effort to make something that fits into a "normal boring loop" cliche, usually you end up with a "boxy boring loop" which is still more interesting lol

>>21957 >takes a serious amount of effort to make something that fits into a "normal boring loop" cliche Not if you're using sonic pi lol. I think normal boring loops are its raison d'etre.

>>21964 well...

>>22050 >:-) Based nose smiley

I finally bit the bullet and switched to max/msp after not getting soykaf done in other languages Sorry linoox

lain, I am looking for something like a VST but designed around the computer keyboard an instrument designed for the power of the keybinding otherwise please share with me your most effective way of binding the music keyboard keys to the computer keyboard

>>16127 I'm about to start with JUCE as well. What are you using to learn it? I have 0 DSP knowledge so not sure if I should study that first or if JUCE abstracts away enough of it for a beginner

>>23728 I've seen music major types enjoy themselves using JUCE after a brief primer on C++, so no deep dive into theory is required. However, if you do want DSP theory intermingled with musical examples I suggest you take a look at these books available (without the exercises) freely online: https://ccrma.stanford.edu/~jos/. I have also heard Designing Audio Effects Plugins in C++ by Will Pirkle highly recommended. I have not read it myself, but it seems to be more applications oriented. Happy Hacking!

I've been messing around with audio (live) programming for a few months now, and found a setup that I'm reasonably happy with. >Supercollider SC is the lingua franca for audio live coding. Most anything else you use in this space will either depend on it or at least interface with it. I use it to whip up simple synths/effects and then control them with tidal cycles. For more complicated synths I'll write them in Faust and then export them as a plugin for SC. I don't actually like the sclang itself at all. The supercollider sound server thing is great but the language is simultaneously too verbose for the kind of sequence/pattern based live coding I've been doing and too limited for developing more complicated DSP software (there isn't even a hood way to "import" external files). This is why I've relegated it to the roll of "glue" but if any lainons have had success with different language frontends for the SC sound server, let me know. >TidalCycles This is what ultimately convinced me to give live coding a shot instead of using a conventional tracker. Tidal lets you layer and combine patterns of synthesis parameters, which are not limited to just note data like in most sequencers. The language side is just a library on top of Haskell, and the server side, "SuperDirt", is implemented in supercollider. SuperDirt, when used conventionally, is a fairly competent sampler with a few built-in effects. However, it can also be used as a generic interface to control synthdefs from tidal. This is mostly how I use it. >Faust Faust is a haskell-like functional language that compiles to C++. Essentially, you write the interface code in C++ (to interact with the audio and graphics apis of your choosing) and then write the DSP code in faust. Faust devs have already written C++ "interface code" so that faust code can be compiled to a standalone GUI application, or a VST/supercollider/puredata/Max plugin (among other options). So, essentially, I use faust to make up for the fact that developing anything substantial in supercollider is a pain in the ass. >JACK Pretty much indispensable if you're doing anything serious with audio on linux. JACK essentially negates the need for a DAW, since I can easily use it to patch between various standalone programs. Practically, this just means that if I can patch into more conventional VST hosts (Carla), multitrack recording software (audacity/ardour), or occasionally standalone soft synths/samplers (hydrogen/zynaddsubfz). >what's missing? The main problem with this setup is that tidal doesn't really have a concept of "arrangement". This is fine if what you're doing is purely tracker music because you can just set each pattern as a seperate variable and work on them seperately before merging them into a larger pattern that constitutes the final song. However there isn't really a good way to integrate overdub-style audio tracks into this. I haven't tried to do so yet, but I imagine I'd probably just write all the sequencer stuff first then record it into a more conventional DAW to do overdubs and mixing. This seems kind of ad hoc though, and is not as convenient to work with as e.g. ableton's midi and audio patterns.

Bumping this thread before it dies. One thing I want to make explicit is that, just like programming in general, there are different levels of abstraction in audio programming. The low-level would typically be C or C++ with heavy use of SIMD instructions via compiler intrinsics or assembly in DSP loops, but also lock-free multithreading using atomics, etc. I recommend reading The Audio Programming Book by Richard Boulanger as an introduction, watching the talks of Timur Doumler on googleTV, and studying the code of Mutable Instruments' eurorack modules (https://github.com/pichenettes/eurorack) to dive into this kind of stuff. The medium-level would be Faust, C++ with a plugin framework like JUCE or D with DPlug (https://dplug.org/), where you are mainly focused on writing DSP loops, you don't have to care too much about GUI code or interfacing with a platform-specific standard. It's mostly about math. >>23737 already posted pretty good resources. I also recommend reading Curtis Roads' Computer Music Tutorial and whatever academic paper you can find on audio processing and synthesis. The high-level is typically the Max family of graphical languages (PureData and Max/MSP) or SuperCollider. These languages are all about describing and generating a graph/network of objects that interact with each other just like the components of a modular synthesizer. Max is slick and offers a great user experience but it is also proprietary and doesn't run on Linux. Pd can run on ARM boards, be embedded into applications with libpd, but you don't get bandlimited oscillators or objects like multislider, matrixctrl and zl by default. Pick your mess of patch cables. SuperCollider is both a language interpreter influenced by Smalltalk -- sclang -- and a server allowing you to connect DSP nodes together -- scsynth. scsynth can be controlled by a Common Lisp REPL (https://github.com/byulparan/cl-collider) and a lot of other languages. TidalCycles is at heart a sequencer controlled by a Haskell DSL, and that's precisely what's awesome about it: to generate complex sequences by passing simple ones through a chain of functions. There is also ChucK, Extempore, Sonic Pi, and much more (https://github.com/toplap/awesome-livecoding). CSound is the ancestor of them all, but it lacks real-time capabilities. One thing is sure: the possibilities are endless.

who /Bela + PD/ here? I quit TidalCycles because Haskell is too beautiful and keeps eating all my time

>>21854 This honestly Most live coders in my country just use it to play minimal techno or house that sound like they're made of Ableton instrument presets

dsd sounds better for fusion rock blues bossa nova black metal - inb4: got into this whole audio thingy for lelz but now i store all older albums in dsd - i just enjoy old tracks way more -

Any lains have experience with Incudine or any of the common lisp Supercollider libraries? I've been wanting to fuarrrk around with doing audio programming in lisp because I really like the idea of being able to produce music declaratively (i.e. It's all just source code) and do it from a lisp repl, and already know lisp. I don't know soykaf about music production though, that's the only thing stopping me and I haven't had time to try to learn how to produce electronic music. Also anyone itt have anything they've made with sc/tidal/etc. that they wanna post?

>>16567 search for the supercollider twitter tag, there are a bunch of people who tweet the code to really weird evolving sounds they came up with. also worth learning some puredata, as miller puckett (the creator) has some lectures on youtube

>>26898 i have one but i think it kinda is like kicking dead whales down the beach, and it's mothballed atm, maybe i should pick it up again. its just the beaglebone is really slow and the real time framework they made for it needs weird optimisations that aren't in any of those programs (sc or puredata). so really you need to do stuff in c++ for anything you need good performance for.

Cool thread, allow me to humbly share a little personal project, a simple UNIX-friendly modular sound-effect generator based on a simple Directed Acyclic Graph structure: https://github.com/sylGauthier/sndc Basically you create a bunch of nodes that you can connect to each others (output of former nodes to inputs of latter nodes). It's not real time, all buffers are generated completely then passed on to the next nodes, so since you have all the temporal information already, you can do weird things like backward echoes, non causal filters and so on. Also the output quality is arbitrary and doesn't depend on your hardware, just the generation speed. It's still a work in progress, I'm working on reverb and proper band pass filters atm.

>>27064 Oh, that's too bad What project caused you to notice its limitations? I've used it to control a granular synth, solenoids and p5js patch using multiple sensors and contact mics (using bonk~), but never stumbled on any performance issues When I used wavetable synthesis using sinesum it started dropping blocks like crazy though

>>27064 >>27297 If you avoid using certain PD objects you can use the Heavy Compiler Collection (hvcc) instead of LibPD, but you might already know that

>>27297 actually since this thread came up i had another little look and i might pick it up again but just for c++ and learning some real time. https://learn.bela.io/tutorials/c-plus-plus-for-real-time-audio-programming/course-introduction/ . they made a tutorial series . I love PD but it's better on my organelle m (which is rasp pi based and much faster than beaglebone). I have the bela pepper thing that i need to fix up because the original version had terrible audio output but they gave out free breakout boards to improve it (but it will be a while til i get soldering it on). I noticed the limitation when i was trying to get orac to run on it which takes code from mutable instruments eurorack modules and allow you to run on bela.

let me just plug the Overtone [1] ecosystem since it hasn't been mentioned. Its a supercollider interface in clojure, which interoperates with Quil [2] (a Processing interface) and Afterglow [3] (a DMX interface). [1] overtone.github.io [2] quil.info [3] github.com/Deep-Symmetry/afterglow

>>27323 >JDK runtime error messages please nooo

>>27323 thanks for this, i had a look at this and it really solves the problems i had with supercollider (the language and the editor is like kicking dead whales down the beach). clojure is much nicer and it goes hand in hand with the quil / geom stuff i've been looking at for generative visual art.

Has anyone managed to get gdpd working? https://gitlab.cristal.univ-lille.fr/mint/godot-addons/gdpd Attempted to run the example on macOS, Windows and Linux but could never get the sound working I'm prototyping a sequencer using Max and Godot, but would like to distribute a cross-platform standalone version in the future. If GodotPD won't work, porting everything to Ofelia seems like the best option https://www.youtube.com/watch?v=mUC5kzcwckw It's still a very early version