OMG, I didn’t know that. That’s nuts. But still… at the end of the day, I look at the audio things people have made with Minecraft, etc. and just smile.
There you go: https://www.coursera.org/learn/audio-signal-processing
I knew this forum wouldn’t let me down! Thanks everyone so far!
Well, I did do this… Bawk!
Need to finish that up really!
Why do you think Java would be bad ?
I mean if you just wanna get the basic Java is easy to understand.
Though i must agree C++ would be a better choice.
There is nothing scary about pointers
yep since were talking about programming audio apps might be better starting with C/C++
Dirt simple can be Python with the wave module to write wav files – all free if you have a computer with a speaker.
The various low latency Bela hardwares are attractive to me for a platform to develop on and to have a finished functional system at the end.
There are many paths up the mountain, but the view of the moon from the top is the same. => Honor different paths and walk your own path.
For realtime sound synthesis/audio programming there is no way around C/C++. Other (high level) programming languages won’t give you that kind of lowlevel control that it necessary in that area.
And, as also already suggested, the Juce Framework is an excellent base which is used in a vast number of professional audio programs.
But I wonder if an absolute beginner in both areas (programming and audio/synthesis stuff) should really start like this. Simply just learning C/C++ can be a quite frustrating experience …
Maybe starting with Max, SuperCollider or Pure Data and spice that up later on with some own extensions coded in C/C++ is the better way.
And when it comes down to hardware to run own patches on Organelle is also a nice option (runs Pure Data patches).
Caution with C++ (and Java as well) is needed, as various things can be happening in the background, like garbage collection, plus it’s not always clear what the compiler is going to do, which can interfere with it’s real-time behavior. (There’s lots of help with understanding this various places.) There are a lot of things that are great additions with C++, and safe in time sensitive programs, so it’s good to use those features. If you stick to C and a few nice C++ things, and are smart about it, you’re fine. Plus plain old C is relatively easy to learn. (Though less efficient to code.)
Of course faster processors and larger memory can smooth over bloat nicely.
i am genuinely surprised no one has mentioned Will Pirkle’s books on making Synth and FX VSTs and VSTi’s and RackAFX.
Well, I mentioned the combination C/C++, because normally your audio program is a mixture of both. C++ is fine for not realtime stuff like the GUI or bootstrapping/initialization and C for the audio processing, where you’ll need “full” control due to the realtime restrictions (no system calls/no allocations etc.pp).
And don’t get me started on compiler optimizations. Even with C these can be a real PITA sometimes.
With realtime programming caution to the smallest details is needed.
Been there too.
I always like to look at key sections or sections inside a tight loop that get run a lot (or stuff that come to the top with a profiler) at the assembly level, the code the compiler generates, 'cuz a simple rewrite, or pulling variables outside a loop, etc can make a big difference. Sometimes a compiler, even with speed optimization turned on, can do some very stupid things. I’ve always been able to get efficient code, with simple changes to the C code, without having to resort to inline assembly, which i hate, being that it is so non-portable.
ADDED: This whole efficiency pursuit can become uselessly obsessive as well – i think about efficiency even when i know it doesn’t matter. Usually though i’m able to rein myself in.
You guys are way too cool for me LOL im a lowly Sql Dev with some light python experience. IUve always been interested in how my favorite boxes work under the hood (ive always assumed some degree of c++ was need, but beyond that I really have no idea).
Following for pro tips as it is a subject I’m vaguely interested in. Like the OP, would be interested in learning to code one day.
@Greatexpectations… Whats your learning type/process like?
Hey dude, good choice… coding is fun most times. But do you intend to have it as a profession or for fun? That can obviously be a important parameter when you decide how and what to learn.
I´ve been a professional programmer for the last 15 years, last 8 as a consultant doing higher-level system development using most of the modern tools available. Mostly .NET though even if the last few years has been interesting with a lots of mobile development (both for android & iOS) - so hit me with ur questions…
Coding as a hobby can be very rewarding if you can actually produce something that others will use.
As the positive feedback is something you want to maximize in a hobby, you would need a something where you can start with simple routines and building blocks that are still usefull for others, and where there is a community of people receptive of your “products”. Thus, even as you have dismissed it in your post, coding in something like Reaktor could actually be the best bet for a rewarding hobby in DSP coding. There, you have many open-source examples of how things are done, within a framework tailored for DSP/sound programming. Even as a beginner, you can quickly use code from different blocks and combine them in useful ways, creating new stuff for others to use. For instance, many Reaktor blocks could really use a stereo version, something you may start as a programming task this evening with nearly no programming experience. Programming a new OSC or filter requires more skill, but would not require you to learn pointer arithmetics in C first, plus several hundred of library functions.
At last, you can use your skills to program whole new synths, and people will be very grateful for your efforts. In summary, Reaktor would be something that grows with your skills, with a far more beginner friendly learning curve than starting from scatch.
Hi Rusty – Saw you lurking around the Korg Prologue SDK thread here too.
The Prologue would be another interesting synth to develop code for – despite it’s (many) shortcomings. Like for instance the 32K code/data limit, the modest speed processor, the moderate limit on control parameters, and the expense (though $2K isn’t horrible for what you get).
But it is nice to have that much parallel power, 8 or 16 processors (meaning polyphony) depending on which Prologue you have.
That said i’ve decided not to pursue it, at least for the time being.
ADDED: Oh and there is also the FX side of the Prologue available to do stuff on too.
I’m an absolute beginner with no prior experience so it would be foolish to imagine doing it as a profession… that said, I am about to turn 40 and I am looking for a career change (I have a PhD in chemistry and currently work as a drug hunter but have grown tired of this work). I’m pretty confident I can learn and use anything but I just need guidance (and some focus/target of what I really want to do…)
You (and others) make a good point here. Maybe I should look at Reaktor first.
It piqued my interest for a very brief moment of time… and that was it
If Korg make it easily available below a certain price point; then I will get one. Apart from that, very little interest.
I’d much rather concentrate that time / energy working on my own hardware where I have full creative control over each/every aspect; rather then being restricted to an external SDK and target device.
I’m quoting myself here because the big take away I’ve experienced using Swift Playgrounds (I’m still working my way through the lessons) is wow, on a curriculum level, this is a wonderful app to teach people like me computer science.
It’s kinda funny. Because now when I look at my son’s Java text book, I can get the general gist of what’s going on. Code is after all meant to be human readable. The basic lessons I’ve learned in Swift are helping me comprehend React. I’m learning new things. I just wish BBEdit would keep up with me.