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

Soul – A language and IDE for audio coding

soul.dev

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Soul – A language and IDE for audio coding

#52

Post by ivarv »

majkinetor wrote: post #46

Just for the sake of completeness and for those new to the topic, here are some mainstream audio programming languages people might also want to take look at: - Csound This is one of the first ones, a little bit dated now but there is ton of material and nice books - Pure Data (max/msp) Graphical audio language, also popular and very nice for beginners - Supercollider Object oriented platform for audio synthesis (sma…

Sam Aaron (original dev behind Overtone) has been focused on building out Sonic Pi ( https://sonic-pi.net/ ) for a few years now and it's an amazing tool aimed at simplicity (literally aimed at ten year olds) and power (used for gigging).

Re: Soul – A language and IDE for audio coding

#53

Post by seandougall »

reggieband wrote: post #34
julesrms wrote: post #19

Earlier quoted context omitted.

Not sure that being able to change the graph dynamically is a particularly good way to work with this kind of thing. In almost all synths, and even DAW engines, they only modify the graph when you modify the project, not while things are running, and that's when we expect you'd do a SOUL recompile. There's a much longer discussion to be had over this which I won't dive into now, but we have thought about many possibl…

You mention custom DSP hardware licensing ... any reason not to target the GPU directly using CUDA or whatever?

I've looked a tiny bit into this sort of thing (using Metal compute shaders), and the problem is that, even with all of Metal's optimizations around CPU/GPU synchronization, the overhead seems to be too high for real-time audio DSP in practice.

The thing I tried experimentally implementing is basically a 128x128 matrix mixer with a little bit of extra processing. On a three-year-old MacBook Pro, the GPU barely had to lift a finger to crunch the data, but the round-trip latency was still high enough that it would struggle to keep up with anything less than a buffer size of 512 or so at 48kHz (which is on the high end for live mic processing). It would be fantastic for offline processing with larger buffers, though.

I haven't tried CUDA or OpenCL, so I don't know if the situation is the same there—but of course they have the problem of vendor support as well.

Re: Soul – A language and IDE for audio coding

#54

Post by seandougall »

julesrms wrote: post #44
gugagore wrote: post #39

Earlier quoted context omitted.

I'm curious what you mean by "wrong shape"? Because GPUs are for for very data-parallel workloads? Or because the latency is high?

Yeah, we made both of those assumptions. But it's apparently less true of the latest generation of compute engines. We probably won't bother with CUDA, but Metal is certainly a viable platform to try. It's one of those things where nobody really knows how it'll do until you try it. Also, we do know a few people who want to use SOUL to write audio code which does need high parallelism. It's not a super-common use-case…

I hope you'll consider writing up your results in a blog post or something! As I just mentioned elsewhere in this thread, I have experimentally found latency with Metal compute to be too high to be feasible, but I would dearly love to be proven wrong, if there's a trick I'm missing.

Re: Soul – A language and IDE for audio coding

#56

Post by julesrms »

sagichmal wrote: post #51

This is cool. Can I have it against CoreAudio or Pulse or anything other than WebAudio?

Have a read of the FAQ and overview docs, or watch the talk: https://github.com/soul-lang/SOUL

The browser-based stuff is just a demo to let people explore the language and learn about what we're trying to do. The actual goal is to create the fastest, lowest-latency infrastructure for audio on all platforms.

Re: Soul – A language and IDE for audio coding

#57

Post by tomduncalf »

jchook wrote: post #55

Any info on the motivation for making an entire language instead of a library for an existing language (e.g. for C, Python, or Go)? Especially if the syntax mimics C-like languages, what important advantages do we get?

The overview at https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... should help explain the motivation. I’m sure Jules can elaborate further :)

Re: Soul – A language and IDE for audio coding

#58

Post by gugagore »

julesrms wrote: post #41
mleonard wrote: post #37

Earlier quoted context omitted.

Hi. Great talk. Basically introduced me to audio development! Given you're experience and the future you're talking about with Soul or a similar language being how audio development is done... what resources and approaches would you recommend someone completely new to the domain study?

Audio dev has always been insanely hard - that's part of the motivation behind creating this! It's hard because you need some serious mathematical skills to understand the DSP itself (that's the bit I'm lacking in..). Then if you're building a "real" product, you're going to have to write in C++ and have a rock-solid understanding of concurrency, real-time coding and many other very tricky subjects which take huge am…

I wonder if the SOUL team has considered looking at Julia, which aims to solve the two-language problem, in which programming languages are either fast or easy. It's in the context of scientific computing, which is usually almost entirely about throughput and not about latency. But I think there's a lot in common.

Re: Soul – A language and IDE for audio coding

#59

Post by julesrms »

jchook wrote: post #55

Any info on the motivation for making an entire language instead of a library for an existing language (e.g. for C, Python, or Go)? Especially if the syntax mimics C-like languages, what important advantages do we get?

We pre-emptively answered this inevitable question in the overview doc: https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over...

The main TL;DRs are:

- this needs to get JITed to compete with C++ performance, so dynamic and interpreted languages are out.

- it needs to stop people doing anything which is real-time unsafe, so any language which involves a heap or GC is out

- it needs to be secure enough to not pose a security risk if deployed to an embedded bare-metal device, so C is out.

- it needs to be super-easy to learn for all programmers, and especially for grizzled old C/C++/Javascript/C# people who aren't into any of that fancy functional nonsense

- it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out.

Post reply on HN