4 ms·

Very ambitious and looks like quite an accomplishment! I've been working recently on several DSP projects, including for web and embedded applications, and I de

Very ambitious and looks like quite an accomplishment! I've been working recently on several DSP projects, including for web and embedded applications, and I definitely appreciate writing performant code without having to write C++ by hand. I couldn't tell from your post and linked material how the runtime works — I see that the high-level graph is handed over to the runtime, but is it interpreted? Compiled? Does it require platform-specific binaries? For my current projects I settled on Faust [1], which has the advantage of compiling to C++ source files (which can then be used with any platform/framework that supports C++), but that has the disadvantage that swapping components in and out (as you describe in the linked article) is not so easy. [1] https://faust.grame.fr/ https://faust.grame.fr/

trypwire 5y ago
Thank you! I've used Faust quite a bit myself, and it has been an inspiration of mine for this project. But indeed, it has limitations that were prohibitive for me, and I'd rather not have to context switch from a DSL for my DSP into some completely different language for the rest of my app if I can avoid it. > I couldn't tell from your post and linked material how the runtime works — I see that the high-level graph is handed over to the runtime, but is it interpreted? Compiled? Does it require platform-specific binaries? Yea, check out this page of the docs: https://docs.elementary.audio/guides/native_rendering https://docs.elementary.audio/guides/native_rendering It is interpreted dynamically by the runtime, and currently does require platform-specific binaries but I'm also building the runtime such that end users can embed the functionality into any app they need