Live data from Hacker News

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

soul-lang.github.io

41–50 of 83 posts

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

#41
post #12

Earlier quoted context omitted.

Hi, one of the developers here. How would it be possible to allay your concerns? I think we've tried to be as clear as possible with our intentions - how could we rule out such possibilities with our license agreement?

"We're currently keeping some of our secret sauce closed-source" What secret sauce is this? What parts of https://github.com/soul-lang/SOUL are closed source?

Joke answer: the bits that aren't in there.

Real answer: Mainly the JIT engine, and the very complex rewriting algorithms that turn multi-threaded soul code into a form that can actually be executed.

We're certainly keen to open-source everything when possible, just been advised by our lawyers not to do that yet. C'est la vie.

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

#42
I tried out SOUL back when it was first unveiled and I have some questions for the 1.0 release:

- Is time/frequency analysis and its analogs a first class citizen? (STFT, wavelets, other real-time spectral/cepstral algorithms)

- How do I embed the SOUL runtime into an application? Can SOUL scripts be used like user scripts in a larger application?

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

#43
post #12

Earlier quoted context omitted.

Hi, one of the developers here. How would it be possible to allay your concerns? I think we've tried to be as clear as possible with our intentions - how could we rule out such possibilities with our license agreement?

Disclaimer: *I'm not your target audience*; I don't plan to use your product even if you made it public domain. I never want to agree to an EULA before starting to develop something outside of a professional setting. That's an immediate dealbreaker for me. But even if I did - I wouldn't be able to disassemble or reverse engineer your software (2.2)? Also - why are there so many clauses in the EULA telling me to obey…

We have two user-bases in mind:

- end-user developers. This is kind of like being a user of any other language, there's no EULA, nothing to sign, you just write SOUL code, test and debug it with whatever tools (which may themselves have a EULA, but probably nothing heavy)

- device and host developers: These are the people writing DAWs, plugins, hardware that can run SOUL code, audio device drivers etc. These are professionals, and licensing is a normal part of life when you're doing this kind of work.

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

#44
post #40

Interesting! I wonder if the patch format has support for OSC messages for external interactions - so far I only found MIDI support, but maybe I missed something...

The patch format is for the same use-case as VST, AudioUnit etc, where OSC isn't really a thing.

OSC is more something you'd want to use for a stand-alone program, which needn't be written as a patch. But yes, would be nice to add some OSC wrappers one day. Maybe it's the kind of thing that someone else will contribute before we get around to it.

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

#46
post #4
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...

Ah, missed the main website (just thought the github one was just that). On soul.dev the examples are indeed easy enough to find.

Looks like an interesting project!

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

#47
post #42

I tried out SOUL back when it was first unveiled and I have some questions for the 1.0 release: - Is time/frequency analysis and its analogs a first class citizen? (STFT, wavelets, other real-time spectral/cepstral algorithms) - How do I embed the SOUL runtime into an application? Can SOUL scripts be used like user scripts in a larger application?

Full support for wide streams (i.e. streams of overlapping windowed blocks, suitable for frequency-domain work) is still to-do (though we've planned for it all along!)

We've tried to make embedding it as easy as possible - there's a DLL, and a simple COM interface and a few header-only C++ classes to load and JIT-compile a patch dynamically. We have an example project showing how to do this. FWIW Tracktion Waveform is doing exactly this, and only has a few hundred lines of glue code to enable patches in a full-blown DAW.

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

#48
IMHO SOUL is a game changer in audio just like OpenGL/Direct3D/etc. was a game changer in the graphics world.

Think of all of the graphics technologies that were enabled by OpenGL/Direct3D/... and consider the equivalent for sound/music.

The trend is clearly going into the direction of application-specific processors and a lot of hardware already has dedicated DSP chips for audio. It is high time that a standard language is proposed to access them in a unified way just like OpenGL did.

Full disclosure: I worked with Jules and Cesare at ROLI/JUCE where Jules was my mentor and colleague. If anyone can pull this off, it’s them.

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

#49
post #31

Cool! For those interested in audio-specific languages, I've had some success with Vult, a transpiled language which runs everywhere, compiles to Pure Data and runs on the Teensy. I used it to make some really powerful, extremely performant filters. http://modlfo.github.io/vult/overview/

Yes, that's very nice. I particularly like the fixed vs float implementation

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

#50
post #12

Earlier quoted context omitted.

Hi, one of the developers here. How would it be possible to allay your concerns? I think we've tried to be as clear as possible with our intentions - how could we rule out such possibilities with our license agreement?

Sadly, I’ve been bitten by this before, too, and even if I love the product, I stay away. It isn’t that I don’t trust you or your intentions now, it’s that intentions (and requirements) change. You asked about allaying fears. Personally for me this means actually take-to-the-bank licensing that I could get through a legal audit, even if hypothetical. Talk of “secret sauce” and future closed source and IP licensing of…

Well, as the person who also created JUCE and its license, I can't really argue with that. :)

We're very keen to make sure that the end-user developers are totally unencumbered and license-free, because we want lots of people to adopt it.

All our licensing is more aimed at device and driver builders - think of it like e.g. openGL - the industry making GL cards and drivers is legal complex, but none of that stuff affects the coders writing GL apps.

Post reply on HN