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

[Ivan_C]

For what it's worth, I'm looking at the VCS3 example and trying to resist the temptation to write an improved one..

Actually I would be very interested to see your take on my code, I just did a plain porting of the original algorithm I put in your thread about the semi-implicit method for the Moog/transistor ladder filter It was just to see how simply one can translate some c++ code into SOUL code, and see its performance. But please don't resist temptation

[mystran]

So what I would like to see in an audio-processing language would be explicit control for these kinds of optimisations. If I could specify that "really unroll this loop no matter what" and "really replace this array with scalars no matter what" then I could just throw that Lua-script into recycle bin.

Yes, we'll certainly support performance hints like that, although of course they'll only ever be hints as we obviously don't want to over-prescribe what capabilities the back-end compiler must support. We already have a [[ ]] annotation syntax kind of like the C++ one for this sort of thing.

The problem with "hints" is that you can't rely on it. When you have an algorithm that is real-time feasible if and only if such optimisations are done, then as long as you can't guarantee that such hints are respected, one is stuck using a code-generator that does them manually. This type of stuff shouldn't even be a back-end optimisation, but rather a front-end feature.

This is basically the same as with "tail-call optimisations" where if you have a language like Scheme or Lua that enforces strict TCO, you can structure complete applications in a completely different way. But when TCO is "just an optimisation" like in most C++ compilers these days, you can't just structure your whole application as one big infinite recursion, because as soon as the compiler decides to skip the optimisation anywhere, you blow up the stack. Yet, most non-trivial C++ applications contain at least one trampoline somewhere, in order to process some state-machine without blowing up the stack.

edit: you can already "#pragma unroll" in C++ as well, but without guarantees it's "just an optimisation"

[mahaya]

...

I could elaborate here, but TBH I'd just be repeating all the stuff from my original announcement talk last year, and the docs we've released in the github repo now, so if it's OK with you I'll use my limited KVR time to try to address some of the (sigh..) FUD..

Thanks, that's perfectly fine. I missed watching the announcement keynote but as you said it fully covers my questions.

[cesare]

...
The problem with "hints" is that you can't rely on it. When you have an algorithm that is real-time feasible if and only if such optimisations are done, then as long as you can't guarantee that such hints are respected, one is stuck using a code-generator that does them manually. This type of stuff shouldn't even be a back-end optimisation, but rather a front-end feature.

I understand, but the aim of SOUL is to target heterogeneous processors + runtimes, with tradeoffs that you as a developer aren't really going to be able to reason about.

If you are at the bleeding edge of what is possible on the hardware you have, then you aren't going to want to loose the control of writing hand optimised code, and frankly, you should be coding in assembler if that is the case, or certainly with compiler intrinsics.

However, for the 95% of the algorithm you are writing, the plumbing in your audio graph, the event handling, the standard filters and FX blocks, SOUL is the answer. There's of course no reason you can't mix and match, although it *will* introduce some memory copies as you'd have to push data into a soul graph, then take the results out to run through your external bits.

Frankly though, rather you than me. I'll stick to writing algorithms that work just about everywhere

[FabienTDR]

What worries me is the slightly over enthusiastic vision depending on the good will of so many external players. All this without short or mid term incentives for them and no predictable business advantages yet toward the long term (Daw, hardware and plugin manufacturers. Your king makers).

Cesare and Jules, please make sure not to oversee this pivotal aspect. I fully trust your technical work to date, I really have no reason to question your visions from this point of view. But I wonder if you aren't underestimating the required effort in social engineering, diplomacy, politics and ehm.. bribing

Cuo bono? It will be difficult to satisfy more than 2 or 3. But if your vision is honest, and this is really more than a population program for Roli's next device, you fully depend on Apple, Avid and Steinberg to join and finance the project long term. Again, in my humble opinion, that's rather ehm.. ..ambitious.

[mystran]

[...] with tradeoffs that you as a developer aren't really going to be able to reason about.

You do realise this attitude is exactly why developers hate compiler vendors?

edit: Just to clarify, I don't mean this personally or anything. It's just that it took years for the graphics industry to finally realise that it's better to just give developers access to as many explicit details as possible (eg. D3D12, Vulkan, Metal) rather than try to let drivers deal with it (eg. OpenGL).

[Zaphod (giancarlo)]

I'm still trying to elaborate some statements, for example the one about dunning, every now and then I come back here to see how it evolves. No problem, I am aware that I do not understand anything and when I read here my confusion increases, then I remember that I have a lot to do and I go back on my three lines of code for Catalina.

[jules]

You do realise this attitude is exactly why developers hate compiler vendors?

When I wrote a library, I quickly discovered that there's a whole category of mistakes you need to avoid making, and this means that you have to make some choices which annoy some of your users because they don't quite understand all the background behind the reason for them.

It was only when I actually wrote a language and compiler that I learned that this principle applies with a whole extra level of seriousness, and the only way to avoid catastrophic future regret is to steer an incredibly conservative line! Especially at this very early stage. Over the next few years as things unfold, it'll become clear exactly what our "power users" want, and we'll be able to take an informed view about the best way to deliver what they need.

But one of the very important things that I've learned from 15 years doing libraries is the "faster horse" principle. When a user (or even many users) ask you for a faster horse, the correct thing to do is not to just take this at face value - it's best to ignore what they're asking for, and ask why they want it, because if they just want to get from A to B faster, you might be able to give them a train instead. Instead of a faster loop, perhaps you really need an accelerated library to do the thing you're trying to optimise, or a new language construct for parallelising tasks appropriately for the type of processor, or something else. But if we just give you a loop unrolling feature because you've asked for it, we'd be missing a trick.

[Youlean]

I haven't looked at SOUL that much, but as far as I know, this is the new language that will be used for the DSP and we can make changes on the fly for testing without recompiling? It should be hardware accelerated in the future or have native C++ speed?

If so, that sounds like a great thing to have. I would gladly use it if it can currently do the following:

• Easily integrate with any C++ project (not only the JUCE)
  Have some built-in functions for FFT, Filters, etc. (Why reinvent all of this?)
  It could be shipped without installing drivers or something else on the user computers. Static lib that will be linked with the project for me would be perfect, but dynamic lib could be an option too.
  Of course, if it is buggy, that won't be good too.

[sletz]

"Easily integrate with any C++ project "

You already can, we did it in the Faust (https://faust.grame.fr) project, see:

https://github.com/grame-cncm/faust/
https://github.com/grame-cncm/faust/tre ... cture/soul
https://github.com/grame-cncm/faust/blo ... atch-dsp.h

[rl]

After wading through seven pages of discussion I couldn't help but having the impression this topic is just about another DAW proprietary (this time Waveform) plugin format. As long as the number of supported hosts < 2, I'm afraid this isn't even a standard according to the infamous XKCD 927.

[jules]

After wading through seven pages of discussion I couldn't help but having the impression this topic is just about another DAW proprietary (this time Waveform) plugin format. As long as the number of supported hosts < 2, I'm afraid this isn't even a standard according to the infamous XKCD 927.

Um, no... in terms of getting the wrong end of the stick, that's about as wrong as you could get!

The entire reason for creating SOUL was to make the least proprietary format ever. We want to run in all DAWs, all hardware, the web, embedded devices, CPUs, DSPs, everywhere!

[rl]

Thanks for answering quickly, Jules. Are you in talks with other DAW manufacturers?

[jules]

Thanks for answering quickly, Jules. Are you in talks with other DAW manufacturers?

We have a lot of contacts in this industry!

Of course even if every DAW jumped on board right away it'd take years for this kind of thing to roll out, so in the meantime we'll be releasing things like VST/AU wrappers that can load and run soul code in hosts that don't support it.

[xhunaudio]

Hi,

tlaking about next Monday, for the ADC 2019 "Build a synth with SOUL" exhibition you said something about a "local SOUL installation"... Are you talking about Tracktion Waveform, a VST/AU wrapper or a standalone software ?