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

Show HN: SOUL Language 1.0 – A platform for writing and running audio code

soul-lang.github.io

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#21

Post by jarmitage »

julesrms wrote: post #15
jarmitage wrote: post #13

Congrats Jules :) What's the latest on using SOUL with platforms like Faust and Bela?

We've had it running on Bela for ages now. This year we'll be releasing the SOUL network protocol, so that we can properly control remote "SOUL venues" on hardware like Bela (our current Bela network is a bit of a bodge to get it running). Faust has also had SOUL support for a while. Not sure what's new over there but maybe Stephane will see this and comment :)

Nice, it's great to see this project go from C++ rant to reality. Can't wait to never write C++ ever again :)

On licensing, how will it work for creators of open source hardware? Will they still need to pay a licensing fee if they are targeting a specific device with closed driver IP? Or could there be an exception there?

Do you also see yourselves supporting open low-level hardware (RISC-V, FPGA, ...?), and in that case would you consider opening your driver IP for those targets?

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#22

Post by jarmitage »

cesaref wrote: post #20
jarmitage wrote: post #18

Earlier quoted context omitted.

Ah, I wasn't thinking of combining Faust and Bela like that, but that raises an interesting possibility. So you're saying it should be technically feasible to live code/hot reload faust.dsp on Bela with no glitching?

Yes, the soul command when playing a patch watches for updates and recompiles when changes are found (then it switches across from the current DSP to the new one when compilation is complete). This isn't totally seamless, as although parameters are retained, any state held within the DSP code (say delay lines) will be reset to initial conditions, but it's pretty good. So then, update your faust code, re-run faust2sou…

Oh boy :~)

Even though this already sounds great, hot swapping state would be the really big deal here. Do you think the Faust program itself might be able to save/load state somehow?

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#23

Post by cesaref »

Tade0 wrote: post #17

Current tools for audio coding are complex and non-portable Thank you for addressing this. I was meaning to get into making VST plugins of my own, but currently in order to do that one has to jump quite a few hoops and often as the work grows in complexity so does the required expertise.

Well that's definitely something we've been wanting to help with.

One of the supported features of the soul system is to export a JUCE project from a soulpatch - it cross compiles to a C++ project supporting all the standard plugin formats, so you can get AU support for OSX, and VST3 support on Windows out of that one project.

JUCE is one of Jules' previous projects and is pretty much the standard for building cross platform audio plugins used by commercial plugin vendors (https://juce.com/)

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#24

Post by cesaref »

rectang wrote: post #11

A few questions which spring to mind: * Can I use SOUL to create freestanding interactive performance environments a la Pure Data? * What prospects are there for beefing up hardware to run more DSP and bring down latencies? Are there, or will there be open-hardware DSP projects which run SOUL, or open-source runtimes which achieve high performance on standard issue CPUs? If the company behind SOUL goes under (Roli, I…

What prospects are there for beefing up hardware to run more DSP and bring down latencies?

Well that's the million dollar question. We're imagining things moving (hopefully) along similar lines to how GPUs have developed, with dedicated processors for audio processing. It's pretty clear though that the current model of distributing binaries for the CPU is not magically going to enable hardware vendors to sell audio accelerator cards, and hence why we feel a change of direction for the audio industry is required.

The way we see this being enabled would be a JIT based approach where the audio driver translates device independent code to run on their given hardware (and the 'soft' rendering on the CPU which is where we currently are for machines without dedicated audio accelerators).

The design of SOUL has this sort of support in mind, with per sample processing and the parallel structure of the DSP still visible within the language, which allows the driver to make threading decisions at the JIT stage, enabling parallelism.

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#26

Post by cesaref »

jarmitage wrote: post #22
cesaref wrote: post #20

Earlier quoted context omitted.

Yes, the soul command when playing a patch watches for updates and recompiles when changes are found (then it switches across from the current DSP to the new one when compilation is complete). This isn't totally seamless, as although parameters are retained, any state held within the DSP code (say delay lines) will be reset to initial conditions, but it's pretty good. So then, update your faust code, re-run faust2sou…

Oh boy :~) Even though this already sounds great, hot swapping state would be the really big deal here. Do you think the Faust program itself might be able to save/load state somehow?

faust isn't in the loop at that stage. Saving/restoring state will be something the soul driver will have to do, and of course, this will then mean this ability works for all code using the driver, not just faust sourced soulpatches.

We've sketched out how this would work, and it's on the project backlog as something we want to support, so at some point we'll improve this area of the runtime.

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#27

Post by tgv »

julesrms wrote: post #4
samuell wrote: post #2

I would have expected a code example on the front page.

Well, that's just a press release page, but it does have a link to the examples: https://soul.dev/examples/ You can also browse the example code on the github: https://github.com/soul-lang/SOUL/tree/master/examples/patch...

Impressive.

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#29

Post by justforyou »

jarmitage wrote: post #21
julesrms wrote: post #15

Earlier quoted context omitted.

We've had it running on Bela for ages now. This year we'll be releasing the SOUL network protocol, so that we can properly control remote "SOUL venues" on hardware like Bela (our current Bela network is a bit of a bodge to get it running). Faust has also had SOUL support for a while. Not sure what's new over there but maybe Stephane will see this and comment :)

Nice, it's great to see this project go from C++ rant to reality. Can't wait to never write C++ ever again :) On licensing, how will it work for creators of open source hardware? Will they still need to pay a licensing fee if they are targeting a specific device with closed driver IP? Or could there be an exception there? Do you also see yourselves supporting open low-level hardware (RISC-V, FPGA, ...?), and in that…

Please answer the above questions.

Re: Show HN: SOUL Language 1.0 – A platform for writing and running audio code

#30

Post by jarmitage »

cesaref wrote: post #26
jarmitage wrote: post #22

Earlier quoted context omitted.

Oh boy :~) Even though this already sounds great, hot swapping state would be the really big deal here. Do you think the Faust program itself might be able to save/load state somehow?

faust isn't in the loop at that stage. Saving/restoring state will be something the soul driver will have to do, and of course, this will then mean this ability works for all code using the driver, not just faust sourced soulpatches. We've sketched out how this would work, and it's on the project backlog as something we want to support, so at some point we'll improve this area of the runtime.

Cool, great to see that in the pipeline.

I can vouch for that being a high priority feature for any interactive audio development, not just for live coding scenarios.

Post reply on HN