ROLI Releases SOUL Coding Language, ‘The Future Of Audio Coding’

ROLI today announced the 1.0 release of SOUL – a new universal language for audio applications, which they say will dramatically lower barriers and expand access for developers creating any apps that depend on audio, as well as providing a more efficient architecture for audio processing.

“SOUL will revolutionize audio app development, eliminating challenges that have impeded developers for too long,” said Julian Storer, Head of Software Architecture at ROLI. “The need for a radical rethink of how audio apps are made has only become more urgent since I started the SOUL project in 2016. I’m tremendously excited about the V1.0 released today and the additional tools to come.”

ROLI touts four main benefits to SOUL:

  • Easy to learn and use: C++, the standard language for audio app coding, is difficult to learn. The SOUL language is much simpler and more intuitive. Browser-based tools and fast live testing make it  easier to use and master.
  • More secure: Sandboxing untrusted third-party code adds performance overheads that are a particular problem for audio coding. SOUL uses an intermediate assembly language called HEART that is safe to run without sandboxing, making SOUL code ‘far more secure’, according to ROLI.
  • Optimized for power and performance: The SOUL language is designed for performance, with its JIT engine matching an equivalent program written in native C++.
  • Low latency: SOUL unlocks ultra-low latency on devices without the need for embedded CPUs and DSPs.

The creators introduced SOUL at ADC 201:

Since then, the team has been iterating based on feedback via the open-source repository.

The SOUL team encourages developers to explore the language on soul.dev, read the documentation on the SOUL repository on Github, and give more feedback as the SOUL toolset continues to grow this year.

If any readers are using SOUL, leave a comment and share your thoughts on it!

 

20 thoughts on “ROLI Releases SOUL Coding Language, ‘The Future Of Audio Coding’

  1. 53924 comments on BehriWhateverClone2000 and zero on this one? Sigh. This is solidly in the BFD category. Perhaps it’s because the article feels like a copy and paste from the press release with zero context added on who Julian Storer is?

    1. Sonic Pi is a high level generative music tool using supercollider as a back-end. It is geared towards livecoding and education.

      This is primarily for writing lower-level DSP, also portable to dedicated hardware like the DSP chips in digital synths and fx, or embedded in other software like VSTs.

      You could probably use this to make an scsynth plugin that could be used from Sonic Pi.

      You could also use it as a generative music tool in and of itself but you’d likely need to roll your sleeves up a bit more than with Sonic Pi.

  2. Given that:
    a) it combines nodegraph (Pd, Reaktor…) with procedural code (supercollider, CSound, SonicPi…),
    b) it’s permissively (ISC) licensed,
    c) the design has being done by knowledgeable people who care,

    Sounds like a win to me 😀

    Thanks for posting.

  3. Having worked with Julian as a C++ developer for ROLI, I can definitely vouch for the technical & architectural solidity of his work. The idea of SOUL was first launched at the Audio Developer Conference two years ago, and now ROLI have followed through. It will be really interesting to see how it is adopted by the industry, and I sure need to give it a whirl!

  4. Being able to quickly try it in a browser is a nice touch — Lately Bass right there in the browser!

    In the faq there’s a lot of writing about audio DSP chips and heterogeneous CPUs. Is there a target architecture that they have in mind? Something like universal audio, or some Roli product? are they thinking of people designing custom hardware (like Modal designing new synths), or something simpler?

  5. From the article:

    ” Sandboxing untrusted third-party code adds performance overheads”

    So does interpreted bytecode, possibly moreso than sandboxing. Furthermore, sandboxing is typically integrated into the operating system,(for example using virtual machines) and therefore less susceptible to hacking. Interpreted bytecode is typically used for portability, such as with java or C#. Using it for security is an example of “security through obscurity”, since the author is betting that SOUL is such an oscure language that no hacker would consider spending time reverse-engineering the bytecode format enough to inject malicious code into the interpreter and/or “app”. (That’s probably a fair assumption. But still not very secure).

    1. That’s actually a misconception about high level language, where they’re conflated with inefficiencies from interpreters like with Python runtime or the JVM. What gives you the performance is the compilers ability to take our code and turn it into efficient instructions. A shitty C compiler makes shitty assembly, and you can write a killer Python compiler that competes with other languages. Having an intermediate assembly language doesn’t correspond to runtime efficiency. If anything, it makes it easier to optimize your the compiler for your target platform. That’s something about HEART they call out in the FAQ.

      I just bring this up because I work with many languages and arguing development time vs runtime efficiency is part of my job. And really you’ve gotta pick the right tool for the job. For me, I can write in Python most of the time because I can provision more compute resources and it’s cheaper than paying for someone to write something more efficient in C.

      I had a pissing contests with a friend in college. I wrote the solution to our homework in Haskell and he wrote it in assembly. Mine was 4 lines I literally wrote on our whiteboard, while he had 75 lines of assembly. I took 5 min and it ran right the first time, he took a couple of hours with debugging. His ran a few milliseconds faster. It was interesting and really pushed us down different paths. We’re both successful coming at problems from different angles.

    2. Both. The assembly or byte code is compiled to native using just in time compilation, so that the inner loops run at basically metal speed. In theory.

  6. I am not really sure to trust anything from ROLI these days. I bought Equator2 November 11, and never succeeded to install the instruments for it. The ROLI connect app doesn’t work properly on my computer. I raised a ticket, and received so far twice the message saying that they will answer at one point to solve my issue. But it has been more than two months now, and still no real answer, and no sign that they have even processed anything. So I wonder what kind of support they will provide to this new Soul product, if they are not even able to keep track of their current business.

    1. This sounds like a very unpleasant experience. But Soul is an open source project, so it should be fine for as long as there are people around who are using it. Maybe Roli should just open source Equator2?

    2. I was in the same situation as you (I bought Equator 2 and it wouldn’t work), but they replied to me within 2 days…so that wasn’t too bad. The reply itself was less fortunate for me though, since I still use a Windows 8.1 laptop with all my music tools (because it just works fine and upgrading is something I really don’t want to spent time on now) but Equator 2 will only work with Windows 10!

    3. Herisson, I also had an installation problem and this was right after Equator 2 dropped, when they were super busy. They had a solution for me within 48 hours. I would suggest sending another message. If you have a Facebook account do it on one of their posts. I have seen them respond immediately to people on there who, like you, are saying they have an open ticket that fell through the cracks. From what I have seen, they aren’t a huge company, but they put out amazing products and I believe they care about their customers.

    4. Soul is a programming language and as such, not a “product” for the end user so your comparison really doesnt make sense.

  7. I had to refund Equator 2 unfortunately , presets was broken and the synth had a hard time loading in my beast of a PC. Looks pretty and the few patches I made sounded ok.

    I’ll have to revisit the thought of purchasing another Roli Synth..(own everything)Equator 2 seems to be their Massive X

    Side note: I kinda miss FxPansion doing their own thing tbh

Leave a Reply

Your email address will not be published. Required fields are marked *