``` $ sh build.sh --build-type Release --install --sudo --clean-all;
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/cups/http.h:39: /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk/usr/include/netinet/ip.h:189:2: error: unknown type name 'u_char' u_char ipt_code; /* IPOPT_TS */
```
...etc
I found a lot wanting in this article. The emphasis on a lack of tooling seems very ill conceived. The #1 DSP tool in use in this industry is .. Matlab.
Yet, it’s not even mentioned.
Here’s how it goes: Matlab is used to model and test everything. Algorithms are developed, refined, tested and evaluated in Matlab, which has ample capabilities to do realtime audio with high performance. Once the algorithm has been demonstrated and proven, it is ported from Matlab to C, and then core parts are implemented in assembly.
This does not take years. It takes months and in some cases, with a great DSP team, even just weeks. Matlab has plenty of tools for doing this properly .. from visual tools, to optimization functions. There are very, very few professional DSP engineers who don’t work with Matlab in this way.
So this article really just felt a bit more like marketing copy designed to sell their product .. and as I got to the bottom of the article to see the mention of the JS event loop and the browser, I felt like the article was intentionally being disingenuous about the real issues. (The real issue with embedded DSP development is that hardware vendors are terrible compiler developers; but this has had the side effect of making great DSP guys into great assembly programmers. You absolutely must use assembly; but you must also absolutely use Matlab.)
And then, there is JUCE. JUCE is rapidly becoming THE tool to use for high performance audio - it dominates the desktop plugin market - but, as it matures, it has become more and more embeddable. There are devs out there who have made millions with JUCE plugins and are now porting their JUCE code to hardware and embedded platforms with a great deal of ease.
If you want to do embedded DSP properly, start with Matlab, get your ideas implemented, port to C++, integrate into JUCE, and then port your JUCE code to embedded, if your BOM budget supports a decent processor - or, port your processBlock() to assembly, if it doesn’t. This is the future of DSP platform development. Meanwhile, Matlab->C->Assembly is a very well refined workflow, and it is quite productive. One of the best reasons to keep those assembly language programming chops sharp.
For prototyping and algorithm development we mainly use python, sometimes domain specific languages like Faust or CMajor but most of the time we go with C++ right away.