Since we seem to have a lot of audio programmers in here, does anyone have an opinion on using non-C/C++ languages for audio development? I've always used C/C++ but newer systems languages like Go and Rust (both have e.g. PortAudio support) seem quite well suited to the task.
Sure, I made a live-codable audio plugin (VST) that runs Lua/LuaJIT. From my experience, the only thing that slows it down is the fact that it uses double floats which are unnecessarily precise. The JIT and memory management are very efficient, especially following some of Mike Pall's recommendations such as scoping all variables to be as short-lived as possible (eg. using do...end blocks to explicitly define scope).
So, I mostly use C (not C++) for my audio code. I won't touch anything garbage collected for realtime DSP at all, so Go is right out.
Rust, on the other hand, I am very keen to explore, especially with some of the SIMD work that's been brewing. Somebody made bindings for the VST2.4 API/SDK already, and I've been mulling over putting together a brief proof-of-concept with it: https://github.com/overdrivenpotato/rust-vst2
You'd have to write in a bit of a dialect of Go to make sure you don't get bad GC behavior. It's possible in Go, unlike many scripting languages, to write in an allocate-up-front style that doesn't generate garbage, in pretty much exactly the same way you'd do it in C. If you write in the C style, you get a lot of C-like behavior, only with memory-safety. But you don't get much support from the runtime for this style; for instance, if you accidentally append to a slice beyond its capacity, the runtime will simply reallocate the array, there's no way to ask it to not do that and throw an error instead or something, beyond not using "append" (hence my comment about the "dialect"). ('Course, there isn't really one in C either; arguably reallocation is better than a segfault here, as one merely risks an audio pop at some point whereas another guarantees it.) There is also no way to prioritize a goroutine.
I think people end up overselling the difficulty here, because people often strike me as speaking as if the 10ms maximum GC delay is actually the minimum or something and as if the GC is running uncontrollably keyed by a random number generator or something, rather than the amount of garbage generated. It's not that hard to imagine an audio application that runs a 50us GC every several minutes or even less often if you preallocate everything. In practice it's not entirely dissimilar to writing in C and avoiding malloc.
But the real level of difficulty is still something that should make you think, especially as you move from "a single filter" to "a full synthesizer suite".
Rust would generally be a better language, as long as you can step up to the somewhat-harder language, and can find the libraries you need. The payoff for the somewhat-harder language is that you'll have much better assurances about many of the relevant issues. It's what I would generally choose for this task, again, given libraries. But if someone did want to use Go because it's a bit simpler of a language, I wouldn't immediately breath flames on them, unless they were being obviously too ambitious.
> It's possible in Go, unlike many scripting languages, to write in an allocate-up-front style that doesn't generate garbage, in pretty much exactly the same way you'd do it in C
I am very interested in this. Do you have any links with more info?
Basically, the link would be the language spec. Go's structs are "value types". Until you deliberately take a pointer or access them through an interface, they're just structs, like C. It also has real arrays.
In many ways, Go is like a scripting language, but it does let you do some systems-like things in a way that Python or Perl or the other similar languages completely don't.
Go typically relies on garbage collection, which is a no-no. Same with Java. This can be worked around, but you may find that programming a GC language with the GC unavailable is not better than C++ (and it may rule out the use of most third-party libraries).
Rust at a high level could be suitable, when well-tested libraries exist for it.
Audio Weaver is a graphical tool for doing audio dsp. You use a drag-and-drop interface to configure your signal flow graph. When you "run" the system your graph is used to dynamically instantiate the necessary low level functions and compose them together. While the design is running you can do live tuning (changing gains, filter coefficients, delays, etc.). The low level functions have implementations on several architectures (PC, ARM Cortex-A and M, Tensilica HiFi 2 and 3, ADI SHARC, TI C66xx, plus a few more). This means that your signal flow graph is cross platform.
DISCLAIMER - I work for the company that makes Audio Weaver.
I'm pretty new to audio programming, but I'm working on a transcoding library in Rust which calls various C codec/container libraries. I haven't done any extensive testing yet but it seems to perform only a little worse than a C version, and I haven't done any optimization yet.
