Once I tried to start a fair discussion... :)

[Vokbuz]

Ah.. KVR.. Whenever I come here I'm reminded why I so rarely come here.

Why?

[jules]

I would love to see it broken down into a simple example: let's say I want to build an EQ like FabFilter.

a) What part is written in SOUL? Is it the calculation of filter coefficients? Or the the applying of the filter itself? Maybe the computation of the frequency spectrum that's in the background? The whole plugin?

b) What is the exact advantage of knowing SOUL is now compiled in the webbrowser or on a Avid HD interface in our ficitonal EQ example? Does SOUL now abandon my secret filter calculation formula and decides to compile it to a better performing but different filter specifically on Avid interfaces?

c) What about external libraries like the widely used Intel Performance Primitives to calculate the spectrum?

I get that SOUL is more of another abstraction layer but it's hard for me to see the big benefit besides implementing just another standard. I mean VST2 is also widely supported and free, still there are dozens of alternatives that need to be supported. Why should that change with SOUL? Probably just a knot in my brain

a) Yes, you'd probably choose to write both the coefficient generation and the processor itself all in SOUL. But it's up to you - you could generate the coefficients in your plugin's support code and pass them in for the SOUL processor to use. You could even have your plugin code-gen a chunk of SOUL that bakes all the coefficients in, and then run that!

b) Well, a web app is a good example of how it'd benefit - if your javascript web-page was supplying SOUL code which gets passed into an external i/o box which can run SOUL natively, then
- it'll be using a faster JIT engine than WASM (roughly 2x faster in our tests)
- an embedded device will probably have near-zero latency (most likely 8-16 samples round-trip)
- yes, common operations like filters, FFTs etc can be accelerated specifically for the CPU and system that's running it, so if your i/o box had a CPU with a fancy FFT accelerator, you'd get that for free without the code needing to ask for it
- it's one less task for your CPU to do

c) Well, the idea is that we'll use all those performance libraries ourselves, in the JIT engines for various platforms. It's silly for it to be the responsibility of the programmer to manually optimise their code for every possible target architecture.

Yep, VST and AU are widely supported, but you're baking a lump of code for a specific CPU architecture + a specific version of the plugin standard + compatibility with only some versions of all the operating systems. You can't run it on the web, and users have to be willing to load a native binary and trust it. And you need to maintain about 5 different variations of the same plugin for all the places people might want to run it. The only way to simplify this whole mess is with an abstraction layer that takes away the native compilation step, and none of the existing formats can do that.

[KenjiDeVries]

Thanks a lot, that cleared things up for me!

[jules]

a) What part is written in SOUL? Is it the calculation of filter coefficients? Or the the applying of the filter itself? Maybe the computation of the frequency spectrum that's in the background? The whole plugin?

oh, I didn't answer the bit about the spectrum..

Probably what you'd do would be to generate the spectrum in SOUL, and then have an output stream feeding back chunks of data to the plugin support code (i.e. your GUI stuff, maybe written in javascript) to display it. You can define your own event type structures, so it'd be up to you what the content of a frame would look like, but it'd probably just be an array of levels per frequency bin.

[jules]

Ah.. KVR.. Whenever I come here I'm reminded why I so rarely come here.

Why?

Sometimes it feels like a kind of self-help group for Dunning-Kruger sufferers.

[Vokbuz]

Sometimes it feels like a kind of self-help group for Dunning-Kruger sufferers.

Here we go. Ad hominem at its finest.

[jules]

Sometimes it feels like a kind of self-help group for Dunning-Kruger sufferers.

Here we go. Ad hominem at its finest.

Nope, nothing personal. I joined KVR about 20 years ago, that's just always been the overall vibe.

I'm lucky enough to spend a lot of time talking to real experts. And also teaching real beginners. Both are great experiences. Then I visit KVR and see endless pages of people bickering with each other over stuff that either doesn't matter or which they don't quite understand, but where they don't seem to realise that it doesn't matter or that they don't understand, but still keep banging on about it.. sigh.

[xhunaudio]

Jules,

let's say I want to make a SOUL (software) driver for 3rd party DAWs/Hosts. You will charge SOUL costs to me (for drivers and/or hardware menufacturers).

But what if I made an OPEN-SOURCE driver ? Can costs be avoided in this case ?

[jules]

Jules,

let's say I want to make a SOUL (software) driver for 3rd party DAWs/Hosts. You will charge SOUL costs to me (for drivers and/or hardware menufacturers). But what if I made an OPEN-SOURCE driver ? Costs can be avoided in this case ?

Not sure I fully understand the question.. Our EULA already allows people to build it into 3rd-party DAWs and hosts, so there's not really a reason for anyone else to want to do that. And there aren't any costs to avoid by trying to reinvent it yourself (?)

[jules]

..I should note that sure, in a couple of years if there's enough momentum, then we might decide to charge some of the bigger corporations for using it in the more commercial contexts. That's why we're keeping the almost-impossibly-difficult-to-write bit as closed-source, so we can keep that option open. But we're not going to make any assumptions now about what will be the right strategy for us in 2022, we'll have to wait and see what's going on then!

[xhunaudio]

...question reposted below...

[xhunaudio]

...question reposted below...

[mike_the_ranger]

I appreciate the honesty, but unfortunately that shifts the context from "we create a standard open to all for the better good" up to, "once we have everyone's using it, we may make big profit from it".

[xhunaudio]

I'll try to make my previous question in a different form - split into 2 separate questions.

- 1st Question -

From github : What is the licensing/business model?

"Our intention is to make SOUL entirely free and unencumbered for developers to use. All our public source code is permissively (ISC) licensed. We're currently keeping some of our secret sauce closed-source, but the EULA allows use of it freely to encourage its adoption in 3rd party hardware and software. Ultimately, we plan to commercialise SOUL by licensing back-end drivers and other IP for use by vendors who are building SOUL-compatible hardware products."

So, their current strategy for SOUL seems to be "Today is free for everyone. In the future we may decide to charge exclusively the hardware manufacturers, NOT the (sofware-only) back-end drivers manufacturers". Is it correct Jules ?

[Vokbuz]

Nope, nothing personal.

It does not have to be personal. It is about moving focus from the topic to characteristics of other participants.

see endless pages of people bickering with each other over stuff that either doesn't matter or which they don't quite understand, but where they don't seem to realise that it doesn't matter or that they don't understand

Or maybe you don't understand something? Dunning-Kruger, you know. Putting yourself on higher ground is not any better than everything you wrote.