I’m too really excited by this approach! Can’t wait to try it out!

I’ve spent quite some of my professional time worrying about how to build a library of DSP algorithms in a way that it’s instantly available (at least in a non-optimized way) on many different processor architectures. But given the sometimes very basic and “special” language support in most DSPs, especially ones that you’d use in consumer electronics, you end up implementing the same algorithms over and over or you get stuck on a certain product line.

Jules, can you roughly outline what needs to be done in order to port a SOUL runtime to a new DSP? And what does the DSP platform need to provide?

If it has a modern C++ toolchain (C++11 and above) it might be quite easy (just compile and maybe optimize some already-written code). But there are many DSPs that only have plain C compilers, or even worse, basically unusable C compilers accompanied by an obscure assembler dialect. :thinking:

I wonder if SOUL can save my soul, too. :sunglasses:


It’s definitely something that I will try indeed. Almost the first thing I thought, actually. Basically ATK is already working on a graph concept and what my JIT does is generate code for that graph, so it’s “just” another backend.

(and thanks for being at ADC :wink: )


Is Roli likely to create a first party hardware acceleration platform or do you prefer to leave that to third parties and focus on the software? I’m thinking something along the lines of a Waves SoundGrid server in various sleek compact desktop and rack-mount physical forms (but probably with an RTOS configured appropriately and hopefully more competitively priced hardware). I imagine something like this, assuming there is enough initial interest from plug-in developers, would be immediately competitive with the likes of the AAX DSP, UAD and SoundGrid platforms because it wouldn’t have the developer barriers to entry typically inherent in DSP or closed-access systems.

Something that’s trivial to configure and looks good (for home users) or integrates into a rack well (for the pros) and just offloads processing without the user needing to think about it would presumably sell very well.

I’m hoping those of us that like using third party copy protection and license management platforms (e.g. Pace) will be accommodated in this new world. Be that for code obfuscation, license management (key in an increasingly subscription-focused industry), or anti-tampering purposes, these services are beneficial to many small and large dev teams for numerous reasons. I’m hoping these systems will not have fundamental incompatibilities with the approach here or else it could easily put off a lot of the big name developers that are heavily invested in those platforms.


I don’t think copy protection needs to be an issue here, SOUL is for DSP only. The DSP is already in a separated file for AAX DSP, UAD, and SoundGrid that doesn’t require copy protection like PACE.


I wish that were true. I know for a fact this happened with TDM plugins - folks crafting code to snoop on and read out other companies’ algorithms running on the same DSP. I encourage you to spend some thought on code security; applying those considerations from the beginning would be much more elegant and effective than dismissing them outright and then trying to hobble something on in hindsight.


This is an industry obsessed with copying what came before it, for various acoustic and psychological reasons. Currently the focus is on analogue hardware and early digital hardware, but there’s absolutely no reason why that isn’t going to become focused on today’s software at some stage. There could be a lot of money to be made copying expensive plugin algorithms and selling them for knock-down prices, especially if it’s quick to churn them out with generic UIs. It’s happening with hardware already. I’m surprised it’s not happening with software in parts of the world where you would realistically be able to do nothing about it. So I think it’s a very legitimate area to be putting serious thought into with new platforms like this, I hope it’s an area that will at least get some serious consideration at this early phase of Soul’s life.


Probably not enough to gain from it, considering the size of the market!


@jules SOUL looks awesome! I’d love to use it for my app because the JIT compilation would really help.

Can SOUL achieve lower power consumption for the common case of larger buffer sizes (where the API overhead is mitigated by the larger buffer)?

Also: is your IR based on LLVM IR?


From the presentation, they are using LLVM, so the IR is probably an intermediate IR, like the C++ AST?


Well, we’d need some kind of compiler that can be used to JIT some code for it - LLVM supports quite a few DSP platforms now, but sure, there will be some old ones which only have proprietary C toolchains where it’d be very difficult (and probably not worth the effort) to target them.


Also worth mentioning that it’s quite likely that the DSP itself won’t be powerful enough, or have enough memory to compile the IR itself, so the driver will be responsible for doing this work in this case.


Exactly – in the early 00s I was consulting with Roland on the plug-in SDK for a DSP card they designed for their VS line of self-contained studio gear. Zero of the companies who went on to port their plugins to that architecture would do so until Roland agreed to put in protection against this kind of snooping about.


Ah got it, thanks! So the main issue will be having a JIT-compiler for the target platform (which could actually run anywhere outside the actual DSP), and then there needs to be a minimal kind of runtime thingy on the DSP that receives and runs the precompiled code?


Jules, thank you again for the SOUL demo, very exciting! I understand you are not ready to share the full source code of the SOUL platform yet. However, could you please share the source code for the 3 or 4 demos that scrolled by in the presentation between and ?
I suppose I could jot it down from the screen but if you since it already in text format that would be so much easier to review. Thanks!


Interesting discussion here: SOUL - SOUnd Language (JUCE/Roli) :


Here’s heavy faust user - and light JUCE user.
The discussion above is quite interesting. I want to ask @sletz (and also @jules) that - is there any difference about an ideal ecosystem between faust and SOUL?
For me, these two seem almost the same, except for just syntax.

Indeed faust’s syntax is difficult to learn. I tried to spread faust for some people in dsp community but most of them could not get used. If its syntax were c-like, user of faust could be more now.

However, now I really easy to write faust code rather than writing c-like syntax like genexpr. I highly rely on one of faust’s strong feature that can make complex feedback loops to build my custom chaotic feedback synthesizer.

I know it’s a very special case but it’s a fact that there’s some minority who likes functional expression and there are some cases which suit a functional expression. Yeah its problem might be just that I’m a minority and there are few needs to develop such a weird synthesizer but one reason audio programming languages exist is to create a new sound and an algorithm for it, right?

I’m really happy to hear jules’s idea in the thread that enables to run faust on SOUL engine! I hope that these 2 environments grow together for the future.
Ultimately, I dream that someday faust and SOUL become completely inter-translatable…


The question is not only about the “syntax”. The Faust functional approach allows to do all kind of semantic reasoning on the described computation itself, have a so called “semantically driven” compilation chain, have the compiler do quite sophisticated simplifications and optimizations in some areas, that are usually more difficult to express in a imperative language.

On the syntax level, yes sure, it can be difficult for people coming from a more “imperative background”. It can be easier to grasp for “new comers”. Programing in Faust means thinking at the “circuit level”, states are (usually) not explicit, which is adapted in some cases, less adapted in others…

And at some level in the compilation chain, the 2 languages can target the same intermediate IR language (a graph of DSP loops as far as I understand Jules’s description) that will be later on optimized and possibly run in a multi-thread context…etc… So AFAICS it means the same runtime and deployment platform will benefit to any front-end language that can generate this IR language, which is great !

So depending of the users background, the specific DSP problem they are coding, the more adapted language can be chosen.


Ah thanks, that makes more sense now, and I missed to read your comment in the thread. There’s a possibility that faust can generate SOUL source code, not only the IR language! That should solve the problems.


Yes, Faust could generate either IR or SOUL. I imagine longer term the right choice would be IR as the intermediate step would just add cost without any tangible benefit. However, the first spec out the door will be the SOUL language itself.

Of course another thing to consider is that you could mix and match SOUL and Faust in a single graph - nothing stopping you doing that!


Mixing languages, yep !
As a demonstration of this idea (in the current model of Faust mixed with C++ code,) Oliver Larkin iPlug2 model was demonstrated at IFC 2018, see
Basically using the dynamic compilation path (libfaust + LLVM) to develop/experiment, then use the Faust C++ backend to statically compile the final project.
SOUL expected more dynamic platform will surely allow interesting experiments…