CMAJOR : considerations

[xhunaudio]

Maybe I'm too much optimistic...

But it would be nice to open a fair discussion on CMAJOR ( https://cmajor.dev/ ) and hear some considerations about this new development approach.

Very interesting project, following its advancements with much interest (similar to RNBO).

One of the most intriguing things is the WASM/WebAssembly related stuff : it would be great if this will finally become a pro audio industry standard.

So, if there's anything to say, this is the right place.

[rafa1981]

Without entering into technical merits, I did read somewhere (was it here on KVR?) the opinion that it was risky to build a business on top of it because of its closed source nature. If they disappear like Soul any business built on top of it disappears.

Section 7 of this EULA wasn't very well received too
https://github.com/SoundStacks/cmajor/blob/main/EULA.md

[mystran]

If they disappear like Soul any business built on top of it disappears.

Apparently the people behind SOUL are Julian Storer and Cesare Ferrari, while the people behind Cmajor are Julian Storer and Cesare Ferrari. Comparing the language references of SOUL and Cmajor it seems that there are some similarities in the syntax and features, though I didn't spend enough time to really figure out if there are actually some differences.

Joking aside, I wonder if this is essentially just a case of rebranding, perhaps for legal (eg. trademarks or whatever) reasons?

[xhunaudio]

Obviously CMAJOR is derived from SOUL, at least its concept and its main members.

It's now heldt by an independent company named Sound Stacks (part of Soundwise, together with NI and others).

They introduced it @ ADC22, but that video will be publicly available not before 4 months (I suppose).

One of the most intersting things it puts on the table is the WASP code export. If WASP itself becomes a standard for pro audio / plugins distribution, it would be a really great turn.

[Jeff McClintock]

c-major has a nice easy to learn syntax, and uses co-routines to reduce the amount of bookkeeping that you need, compared to writing the classic 'for( i = 0 ; i < sampleframes...' style of loop we are all used to.

unfortunately, I have a large investment in C++, and this makes it very costly to consider jumping to a new language. So for this reason I expect c-major will gain more traction with people just starting out with plugin development.

.I would have really liked to have seen all the same stuff (WEBASM, modularized DSP components) paired with C++ instead of a new language. Especially since C++ is gradually becoming a 'cleaner' and safer language anyhow.

[wrl]

One of the most intriguing things is the WASM/WebAssembly related stuff : it would be great if this will finally become a pro audio industry standard.

An industry standard in what way?

I saw you posting about WASM in the CLAP thread recently as well and I'm very interested in knowing what improvements you see WASM providing over the current native-compiled ecosystem. Personally, I see some theoretical benefits from WASM but I don't see it solving any of my actual development pain-points.

-w

[FigBug]

Joking aside, I wonder if this is essentially just a case of rebranding, perhaps for legal (eg. trademarks or whatever) reasons?

Soul was a ROLI project and ROLI went bankrupt, reformed as Luminary with a focus on beginners. Soul no longer fit into their plans. Not sure if Julian/Cesare quit or got laid off, but they had to restart the project without any existing IP.

[xhunaudio]

..

Just to explain it in 2 words (because I talked about this aspect so many times and I'm boring myself) :

Build a "WASM-like plugin" today (just once) and it will run on any past, present, future CPU, GPU, Barebone, ASIC, etc. with native-like processing speed.

This WASM-like runtime could be sandboxed and completely safe.

No need to ask anyone his (its) permission to deploy for this or that format and/or for private notarization systems.

Several high-end companies like Reason Studios are (quietly) using this WASM-like from years. The only missing point here is an open standard adopted by the whole industry.

I would call the WASM-like approach a groundbreaking advancement, but who knows...

[wrl]

Thanks for responding.

Build a "WASM-like plugin" today (just once) and it will run on any past, present, future CPU, GPU, Barebone, ASIC, etc. with native-like processing speed.

"Native-like" is currently a 2-3x slowdown. Sure, runtimes will improve, but (as with most web technologies), we'd be hooking ourselves to standards controlled by hugely powerful entities (Cloudflare, Google) and just hoping that our incentives align with theirs. Are you contributing to any WASM runtimes right now?

Furthermore, if WASM becomes a standard audio plugin binary format, plugin developers cede a substantial amount of control to hosts. I personally wouldn't want to be in a situation where there's a huge performance difference between hosts on the same computer because the host devs decided to use different WASM runtimes, or develop their own buggy one, or a user is using an old version of the host, etc etc. Really amplifies existing issues we've already got.

And in terms of UI, we'd end up with, what, just HTML/JS for everything? Brings its own upsides and downsides. And, personally, that seems like a pretty boring monoculture.

Being able to use the same binary format for any new CPU that pops up is compelling, but last I checked there weren't even any RISC-V CPUs with the vector extension available yet, and I don't really see anybody chomping at the bit to port their entire OS and production systems over for another... 10 years? 20?

In short: it's not all upsides, and I feel that the downsides of such an approach are overlooked.

This WASM-like runtime could be sandboxed and completely safe.

Sandboxing gets us like 98% of the way there with code we already have today, and IPC overhead is going to be less than WASM call overhead. Sure, with JIT/AOT that could be reduced, but, again – we already have sandboxing today.

Also, when it comes to "completely safe" – how are you verifying your plugins right now? ASAN? Valgrind? Are you fuzz testing? Property-based testing? Doing any symbolic verification or formal methods? Personally, I feel like real-time audio as a field could use more influence from the safety-critical software field.

"Safety" isn't a binary thing, and it's not like WASM will magically make plugins never crash again. Crashes would look different and (probably) not bring down the host. But, again, if crashing the host is the concern, we already have sandboxing.

Nonetheless, this seems to be how most commercial WASM supporters are using it presently: sandboxed micro-containers for edge computing.

No need to ask anyone his (its) permission to deploy for this or that format and/or for private notarization systems.

Firstly, I don't like notarisation any more than anybody else, but pretending that Apple wouldn't head this off at the pass is just naïve. They already restrict JIT on iOS, and even AOT compilation would need some sort of ephemeral signature to be able to run on Mac. Again, I don't consider Apple friendly and I don't like the notarisation and codesigning requirements, but I'm wary of clever workarounds, because Apple have shown themselves willing to cut them off.

Several high-end companies like Reason Studios are (quietly) using this WASM-like from years. The only missing point here is an open standard adopted by the whole industry.

As a counterpoint, Apple was using an LLVM IR-based format called "bitcode" for watchOS apps for the same reason – compile once, run anywhere. However, in the newest Xcode, they've deprecated the format entirely and will be removing it in the future.

In short, I'm not convinced. I'm keeping my mind open, but, for me, there's a lot of downsides that go completely unaddressed in these discussions.

-w

[Jeff McClintock]

Several high-end companies like Reason Studios are (quietly) using this WASM-like from years. The only missing point here is an open standard adopted by the whole industry.

I would call the WASM-like approach a groundbreaking advancement, but who knows...

To elaborate. Reason are using C++ like the rest of us. Only they don't compile all the way to the specific CPU, they 'half' compile to a CLANG intermediate format.
And that intermediate format can then be shipped and JITTED to any particular CPU, e.g. Arduino, Intel, Apple Silicon, Web Assembly.

So Reason are not developing in Web Assembly, web assembly is just one of many potential targets they can get from C++. So perhaps C++ is already the open standard we need?

[xhunaudio]

I always said WASM-LIKE, not Google's WASM or Disney's WASM. One example could be the former "HEART".

Performance is excellent, as for today's Reason RE or Cherry Audio modules. Also if there was a performance penalty, all other WASM-like advantages are so great to worth its introduction.

I just like the idea of an intermediate C-like (not suited for most commercial scenarios because of code readability) or ASM-like to distribute and then compile at runtime.

@Jeff : exactly, you can develop in any language you like and distribute just one intermediate format (I called it WASM-like but it's just a name), compiled at runtime for that specific hardware the end user owns.

The point is to change this (today) :

develop -> compile -> distribute -> run (end user side)

into this :

develop -> distruibute intermediate -> compile and run (end user side)

I didn't contribute to the WASM cause, just because I'm not an expert in that field and my contribute would be negligible or null. I'm not good enough but there are many (a bunch of) talented people in that field out there.

WASM-like would run at driver level (like ASIO), not DAW's. Today your latency is ASIO driver dependent, not DAW dependent. The same is for WASM runtime performance. This driver could also be open source.

And so on... and on...

I'm really tired in upgrading my full dev environment every 5 years. It's really energy consuming and doesn't generate new products. It's like building a hardware synth and constantly upgrade it because the AC electrical powerline change its specs every 5 years.

I see a huge potential in that (WASM-like) and an enormous (and growing) need for a different approach. Maybe it's only my impression, but every time there's a proposal (not even explained in detail), there's always a preventive attack just to say "It will never work, I am the expert, not you".

[wrl]

Performance is excellent, as for today's Reason RE or Cherry Audio modules. Also if there was a performance penalty, all other WASM-like advantages are so great to worth its introduction.

RE are AOT-compiled. And it's not "if" there was a performance penalty. There is a performance penalty, and at present it's a 2-3x slowdown. The question of whether the upsides are "worth" the downsides is one I'm trying to better understand. Simply saying they are doesn't really push the discussion forward.

WASM-like would run at driver level (like ASIO), not DAW's. Today your latency is ASIO driver dependent, not DAW dependent. The same is for WASM runtime performance. This driver could also be open source.

Are you proposing that the whole DAW would run in kernel space?

I'm really tired in upgrading my full dev environment every 5 years. It's really energy consuming and doesn't generate new products. It's like building a hardware synth and constantly upgrade it because the AC electrical powerline change its specs every 5 years.

I see a huge potential in that (WASM-like) and an enormous (and growing) need for a different approach. Maybe it's only my impression, but every time there's a proposal (not even explained in detail), there's always a preventive attack just to say "It will never work, I am the expert, not you".

I mean, I felt I made some decent points, and here you're just dismissing them as an "attack". I'm just trying to have a constructive discussion here to see if there's anything I've missed, but you've glossed over almost everything I've brought up.

-w

[mystran]

I think the whole "native code" thing is bit of a misnomer, as really it's usually really the language safety that carries some overhead when compared to an unsafe language. Whenever you can speed up an algorithm by doing something that a safe language can't statically prove safe (and therefore has to insert a runtime check), you have a situation where an unsafe language is faster. Even though the question of how to reduce these cases and narrow the gap (eg. by new language primitives? type systems?) is certainly interesting, Rice's theorem pretty much guarantees that a "sufficiently smart compiler" can never exists.

I don't think you need a language that's quite as much of a minefield as C or C++ can be, but I think it's reasonable to expect to match them in performance if you start from the assumption of perfect safety.

[xhunaudio]

I mean, I felt I made some decent points, and here you're just dismissing them as an "attack".

-w

That was my first impression - if I misunderstood then you have my apologies, wrl.

I give up.

[jupiter8]

Sounds really interesting. We'll see how many DAWs implement it natively.

https://www.youtube.com/watch?v=qGVyaEVH0o0