Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elementary Audio: a modern platform for writing high performance audio software

elementary.audio

Post reply on HN
Print view View original

21–30 of 110 posts

Re: Elementary Audio: a modern platform for writing high performance audio software

#21

Post by danuker »

trypwire wrote: post #17
iainctduncan wrote: post #15

Maybe I'm missing something from my quick read, but the idea of using this for plugins seems like a real misfire. I'm curious whether the devs come from the pro audio world at all. It's one area where prioritizing for development time by using high level garbage collected languages just isn't done because your user is always concerned with how many instances they can run and what the lowest latency they can get is, a…

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes great care to deliver that; it's a JavaScript "frontend" API but all of the actual handling of audio is done natively with high quality realtime constraints. The core engine is all native C/C++, and we run in the web by compiling to wasm and running inside a we…

> by compiling to wasm

TIL WASM bypasses JS completely, including its memory management.

Re: Elementary Audio: a modern platform for writing high performance audio software

#22

Post by trypwire »

moron4hire wrote: post #10

One of the biggest problem I have with WebAudio API is managing nodes. The API is extremely verbose, when you consider that anything interesting will need to be composed of dozens of basic nodes combined in different ways. You'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…

I couldn't agree with this more. Even beyond the web audio API, we have similar graph APIs in the low level/native C++ world that become unmanageable in their complexity simply due to an inability to compose and manage transitions with ease.

This is exactly one of the difficulties that Elementary aims to address, whether you're running in the browser (where indeed, Elementary uses almost none of the actual web audio api), or natively.

Re: Elementary Audio: a modern platform for writing high performance audio software

#23

Post by jerrysievert »

TheOtherHobbes wrote: post #6
ushakov wrote: post #4

so 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.

have you looked at iplug2?

https://iplug2.github.io

since I was already making my own knobs and panels for vcvrack, it was an easy fit for building out vst3/au plugins.

Re: Elementary Audio: a modern platform for writing high performance audio software

#24

Post by Flankk »

trypwire wrote: post #17
iainctduncan wrote: post #15

Maybe I'm missing something from my quick read, but the idea of using this for plugins seems like a real misfire. I'm curious whether the devs come from the pro audio world at all. It's one area where prioritizing for development time by using high level garbage collected languages just isn't done because your user is always concerned with how many instances they can run and what the lowest latency they can get is, a…

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes great care to deliver that; it's a JavaScript "frontend" API but all of the actual handling of audio is done natively with high quality realtime constraints. The core engine is all native C/C++, and we run in the web by compiling to wasm and running inside a we…

That's great on paper but how do I actually use it? If I want to play back a wavetable you have el.table() but it's missing the oversampling and decimation tools required for antialiasing. The el.lowpass() is a biquad which is not suited well for modulation. How can this compete with JUCE when the documentation and features are so sparse?

Re: Elementary Audio: a modern platform for writing high performance audio software

#25

Post by iainctduncan »

trypwire wrote: post #17
iainctduncan wrote: post #15

Maybe I'm missing something from my quick read, but the idea of using this for plugins seems like a real misfire. I'm curious whether the devs come from the pro audio world at all. It's one area where prioritizing for development time by using high level garbage collected languages just isn't done because your user is always concerned with how many instances they can run and what the lowest latency they can get is, a…

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes great care to deliver that; it's a JavaScript "frontend" API but all of the actual handling of audio is done natively with high quality realtime constraints. The core engine is all native C/C++, and we run in the web by compiling to wasm and running inside a we…

Ah cool, after I posted I was wondering if this was the case. I was just thinking "maybe the renderer is in WASM"?

That's pretty cool, it will be interesting to watch. I do something very vaguely similar in my computer music work where Scheme orchestrates C level objects.

Personally, I wouldn't want to use JS as the high level orchestrator myself as it's such a dog's breakfast of a language, but I can see that many might.

Re: Elementary Audio: a modern platform for writing high performance audio software

#26

Post by fxtentacle »

TheOtherHobbes wrote: post #6
ushakov wrote: post #4

so 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.

Last time I checked, a perpetual JUCE license was priced similar to 3 days from a C++ freelancer. I've never heard it being called out on price before.

Re: Elementary Audio: a modern platform for writing high performance audio software

#27

Post by iainctduncan »

trypwire wrote: post #17
iainctduncan wrote: post #15

Maybe I'm missing something from my quick read, but the idea of using this for plugins seems like a real misfire. I'm curious whether the devs come from the pro audio world at all. It's one area where prioritizing for development time by using high level garbage collected languages just isn't done because your user is always concerned with how many instances they can run and what the lowest latency they can get is, a…

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes great care to deliver that; it's a JavaScript "frontend" API but all of the actual handling of audio is done natively with high quality realtime constraints. The core engine is all native C/C++, and we run in the web by compiling to wasm and running inside a we…

You should really fix the initial impressions you make from the site to get that front and centre though. Experienced audio devs are going to dismiss this unless you make it clear very quickly.

Re: Elementary Audio: a modern platform for writing high performance audio software

#28

Post by bricklebrack »

trypwire wrote: post #17
iainctduncan wrote: post #15

Maybe I'm missing something from my quick read, but the idea of using this for plugins seems like a real misfire. I'm curious whether the devs come from the pro audio world at all. It's one area where prioritizing for development time by using high level garbage collected languages just isn't done because your user is always concerned with how many instances they can run and what the lowest latency they can get is, a…

Hey, Nick from Elementary Audio here. You're totally right that in this domain you have to be extremely careful with performance and latency. Elementary takes great care to deliver that; it's a JavaScript "frontend" API but all of the actual handling of audio is done natively with high quality realtime constraints. The core engine is all native C/C++, and we run in the web by compiling to wasm and running inside a we…

This is my new favorite comment for illustrating the perilous future of general computing and how it needs to be taken away from JavaScript if we have any chance of survival. Electron, Webassembly fetishism, the pursuit of language synchrony at the expense of common sense, it all gets you this. This comment. Right here. This is the future of software and it should scare the shit out of you.

Let me get this straight: you realized latency was a concern, so you wrote in C/C++ (which, exactly?), then turned it into wasm so you can run it in a Web worker? What the hell was the point of that? That’s like saying you bought an M6 and converted it to a foot-powered bicycle. What exactly do you think wasm does? You seem to be implying that you think the native engineering you invested in continues to matter, in the same way, after you do that. You also imply heavily that you understand the wasm you’re executing to still be native. Do you think that? Do you understand what you’re giving up in the Web worker? As in, directly tied to latency and real-time requirements, your whole reason to go native in the first place?

Whatever your response is, deep down, you and I both know it’ll be justification to do Web things for Web’s sake. I know this because everyone I’ve had this discussion with has played the same notes (imagine the deployment model!) while failing to understand that they’re justifying their preference. The only people who build Web stuff want to build Web stuff. In the high performance sphere, of which DSP is a very mature practice, this looseness with the fundamentals of software is going to put you out of the game before you’re even started.

Re: Elementary Audio: a modern platform for writing high performance audio software

#29

Post by reggieband »

What a crazy coincidence. I just spent the last couple of days doing a survey of audio engines with a mind to find those that could run in wasm.

Did you write your own engine or are you built on top of csound, supercollider, ChucK or something else? How do you compare against the higher level or pattern based implementations like Sonic Pi, Tidal Cycles, Overtone and Cabbage Audio? How about libraries like LibPD or even Max/MSP?

I was even considering this space myself and on my list of todo's was checking out the licenses of the above to see what the ramifications of deploying a commercialized version of them would be. However, I must admit that the market for audio software is incredibly split. On the one end are the high-end audio effects with eye-watering prices. On the other OSS end many of the devs are literally begging for scraps on Patreon barely making enough to survive. There doesn't seem to be an in-between. I am very curious what you believe your market will be.

Post reply on HN