Elementary Audio: a modern platform for writing high performance audio software
1–10 of 110 posts
Re: Elementary Audio: a modern platform for writing high performance audio software
#2Re: Elementary Audio: a modern platform for writing high performance audio software
#3Re: Elementary Audio: a modern platform for writing high performance audio software
#4Re: Elementary Audio: a modern platform for writing high performance audio software
#5Re: Elementary Audio: a modern platform for writing high performance audio software
#6so this is basically a paid Web Audio API wrapper?
It would be huge if you could make cross-platform AU/VST*/AAX without the costs of JUCE, but I suspect that isn't on offer here.
Re: Elementary Audio: a modern platform for writing high performance audio software
#7so this is basically a paid Web Audio API wrapper?
It does say you can make plugins, but the link doesn't work. It would be huge if you could make cross-platform AU/VST*/AAX without the costs of JUCE, but I suspect that isn't on offer here.
Re: Elementary Audio: a modern platform for writing high performance audio software
#8so this is basically a paid Web Audio API wrapper?
It does say you can make plugins, but the link doesn't work. It would be huge if you could make cross-platform AU/VST*/AAX without the costs of JUCE, but I suspect that isn't on offer here.
you can make cross-platform plugins without JUCE by using iPlug, Faust or even Rust
the selling point of this seems to allow js/web developers to build plugins
and we already know what happened when web developers were allowed to build desktop apps (Electron)
luckily given real-time and cpu constraints this might never happen to Audio Plug-ins
Re: Elementary Audio: a modern platform for writing high performance audio software
#9Re: Elementary Audio: a modern platform for writing high performance audio software
#10You're given a very basic set of primitive nodes, from which you can construct pretty much anything else. But those things you construct will never be "nodes" themselves. You can't create synthetic nodes or subclass node types. But then many of the basic nodes are useful on their own. So you end up in a bind of having two different provenance branches of audio "node-like" things and need to know which is which before you can connect any one of Column A to any other of Column B, or vice versa.
You're also on your own in terms of keeping track of those connections. Once a node is connected to another node, there is no in-API way of telling what nodes a node is connected to, or what nodes connect to a given node. There's a whole, huge, potentially cyclical graph structure sitting around in memory that you can manipulate but never inspect.
With how hard everything is to keep track of what is where, you can easily end up in a situation where old, now-disconnected or unused nodes stay resident in memory and never get garbage collected. Some developers then punt on tracking connections at all and expect the user to reload the page if there is a major change in audio setup (coughcoughGoogleOmnitonecoughcough).
So when people talk about how Web-based gaming really hasn't taken off or replaced the haunting specter of Adobe Flash, and then point at WebGL as the problemm, I kind of laugh. WebGL is the least of your worries.
Anyway.
Elementary Audio seems to end-run around all that by A) only letting you declaritively define your audio setup, and B) running everything in a single Audio Worklet, thereby bypassing the majority of the Web Audio API.