This is also the source of most headaches in C.
Manually managing memory, remembering to free what you’ve allocated when you’re finished with it, is an enormous source of “memory leaks”. Suddenly, your stack is smashed and you’re left trying to pick up the pieces. Rather awful in embedded firmware land.
Move to Kubernetes and you don’t need to worry about this as much!
However, you now need to understand deployment sets, replica sets, nodes, node pools, pods, taints, tolerations, docker, ingresses, cert-manager, helm, green-blue deployments, terraform… the list goes on and on and on. Bit of a horror show, but at least you’re not woken up at 2am because a service fell over.
I would start by learning assembler, write your own operating system, drivers and a zero latency audio framework 
On a serious note, it might be easier (and more fun) to develop Audio Unit plugins instead, but I think those only work on macOS/iOS.
Try using AI to help 
Hehe cheers, yeah i’m not in that situation anymore anyways, but some places are just not open to that type of change unfortunately 
For some reason I’m getting flashbacks to my time dealing with Agile/Scrum companies. Sprints, stakeholder meetings, forecasts, empiricism and of course the daily scrum. I’m still in therapy trying to cope with the traumas lol 
All good! More of a cheeky poke at k8s tbh, I’m currently working on a legacy k8s system alone, the previous dev team left and I had to pick up the pieces trying to maintain all of this.
Honestly, probably with good reason they are resistant to change: I think a lot of people jump on the tech because it’s shiny and new. They don’t quite understand the amount of time required for a dev “team” to keep the system in a polished, working state. And the cost factors of it being done badly.
Back on topic:
I’ve heard good things about the rust audio library.
Rust is a much more modern approach to system level programming, it’s compiler is top notch and incredibly helpful at making sure you write idiomatic code. I’ve got little to no experience with this, but I do know it can create binaries that a C application can interact with.
Writing the core DSP application in rust, then getting the VST SDK to shim it would probably be my approach for this kind of thing. Raw C is a ball-ache but you’d probably gain a better understanding of the implications of the code you write, as C will not hold your hand. C will instead rip the arm off and bash your head in with said arm if you do something wrong. But it’ll do it fast.
EDIT: Looks like Rust have started a native VST library, but it’s not complete yet. Updated the link to the RustAudio github root.
EDIT2: Also, Elektron are moving to Rust for some of their development. I think they’ll likely be doing assembly for the super low level audio DSP, but if it’s good enough for elektron, it’ll surely be good enough for us plebs :).
Indeed
The solution for that in C is actually the same as the solution for audio programming in C# or Java.
You have to declare all of the memory you are planning to use at initialisation of the program and avoid dynamic memory allocation as much as possible by using things like circular buffers etc.
The main difference is that in C it’s obvious that you should do this as the program becomes much more complex if you don’t
In C# or Java the non expert programmer will just create objects willy nilly and then see that the performance is horrible, but not understand why lacking the knowledge of how to analyse GC pauses as a cause of latency.
Absolutely, hence the comment in the next post about C being a good place to start, albeit baptism by fire. You’ll have a better grasp of how memory management works, and how to write more efficient programs, but fuck me, you’re going to be screaming at the PC in comparison to something like Java or C#. You’ll become paranoid or “defensive” as a programmer, which is inherently a good thing.
I think that Rust gives you a nice middle ground where the compiler should help guide you by refusing to compile when it detects the possibility of memory leak “run time errors”, whereas C will let you build code with potential runtime leaks, and doesn’t bother to tell you about them til you stumble upon them.
You shouldn’t rely on the compiler to catch these, but I think that it’s probably quite helpful for a beginner.
What he said.
As a bit of a curveball.
If your objective is just to learn how to do audio programming and you want something you can share then JavaScript is not a bad idea.
The APIs for working with audio are a little bit weird, but pretty OK if you stick with Chrome. It’s kind of frustrating working with a language that only supports floating point numbers (Although typed arrays help here).
The big plus is you can do it with any text editor and a web browser and it’s really easy to stick it on the web and share it with your friends if you want to make a simple synth / drum machine / voice changer in a web page.
As a dev, I’m kinda dissapointed in all those “don’t even bother” posts.
C++ and its manual memory management isn’t THAT hard in context of audio processing on common platforms. And most of all: We’d still be stuck on old crappy proprietary software if it wasn’t for people that actually DID bother.
Anyhow, I’m basically just replying to recommend reading this book to anyone with the slightest interest in digital audio processing.
OP is not a dev. Describes themselves as a “novice coder”. I would not respond the same way if you asked (though you probably know more about it than I do).
Would you give this advice to someone looking to make midi effects (no DSP)?
PureData or Max/MSP Would be my go-to for MIDI.
My next choice would be Python on a Pi
Specifically referring to c+
If you can get your hands on a norns, its MIDI libraries are great - Lua is still faster than Python for real-time applications, and probably about on par as far as learning curve. My second choice would be SuperCollider, mostly because I’m not into graphical programming like PD/Max.
Edit: ah, was typing while you were replying. Whoops
(off topic) cool fact about Rust is that Linus Torvalds recently announced that Linux Kernel will start taking contributions in Rust, which says a lot about maturity of this lang and where it’s going…
If you want to make a MIDI effect, the first question is whether you need to integrate with a DAW or if it is fine to just talk directly to system MIDI ports. If you want to be in a DAW, you need to make a VST. The VST SDK is C++, so you will either need to build the VST in C++ or build a thunking layer for your preferred language. At that point, you may as well do the whole thing in C++ and gain the simplicity of a single language.
If you don’t need DAW integration then you could use C++, Python, Ruby or any other language that has a working MIDI library.
The best tool is the one that you are comfortable with and can do the job. Sometimes you do need to learn a new tool, but not always.
They’d be iOS apps and word on the street is stay away from what apple is pushin’ (swift)
