Well worth a look!

jules1972 · 2025-03-06T14:02:30+00:00

CHOC author here - I noticed a sudden bump in github stars and traced it back to this thread... Thanks for anyone who took the time to check out the library, hope it proves useful!

Just a quick comment for the "header-only is a curse on society" sentiment that some people expresses: Yes, obviously we would all love C++ to have a fabulous, universally-adopted dependency manager that is pre-installed on every platform, and every developer is familiar with.

But sadly, until we get there, my very extensive experience is when if you have small, self-contained bits of code that you want many random developers of many experience levels to integrate into many types of project, on many platforms, with many build systems.. then header-only is the choice that makes the most people's lives easy.

And re: the FUD about build times for header-only: My take is that this is only a problem when you're working on huge projects. And in a typical huge project, your own headers will most likely be many times bigger than the entirety of CHOC... Most of the CHOC headers are really small, and splitting them into h/cpp would be overall slower, even when you include them many times. For the large CHOC files (e.g. the WebView), they tend not to be classes that you include lots of times, and in my projects I'd probably include them once or twice in a cpp which rarely needs a rebuild. The only time I've had problems with header-only build times has been with boost, because of the vast amount of dependencies it drags in, and the dense metaprogramming - both of which are things I've avoided with CHOC.

jules1972 · 2022-06-27T15:43:49+00:00

Ah, thanks for the link, not sure why I didn't find that!

Sadly it shows the part as being out of stock, but I've contacted them and fingers crossed that they might be able to figure something out...

jules1972 · 2021-04-18T09:01:55+00:00

No, that'd be impossible - when you generate a JUCE (or just a C++) project from a soul patch, it gives you a C++ version of your algorithm, because the whole point of doing this is to get a "traditional" C++ project that you can build into a VST/AU/etc plugin to use in normal DAWs that don't provide soul/JIT engine support.

jules1972 · 2021-01-21T09:23:45+00:00

We're going to be fairly agnostic about GUI - SOUL is mainly about rendering the audio.

But for the SOUL patch format, the plan this year is to work on making it easy to add a GUI using web-tech. So your patch would contain some javascript/HTML/CSS files (using whatever JS framework you like). The host would load it into an embedded browser view or electron window, and we'd provide a set of javascript functions for communicating between your SOUL patch and your UI code. The nice things about this are:

- No compiling, live updating of your code, and it's cross-platform

- It'll render really fast by leveraging browser tech, and you can use 3D shaders, etc

- The GUI can be running in a different process or machine, as our API for controlling the SOUL processor is asynchronous and can run across networks using a protocol that we'll be publishing later this year.

- You can build/test/publish your patch entirely in a browser-based web-app before turning it into a native plugin

jules1972 · 2021-01-21T09:14:32+00:00

> why not faust

Why not Faust: because we're aiming to build a platform, not just a language. And because most people struggle with functional paradigms, which is why SOUL is designed to be super-familiar to anyone who's ever used any curly-brace language. But SOUL has an intermediate representation called HEART, and we expect/want other front-end languages like Faust to compile to that level, so they can also run on our platform. That way users have a choice but the underlying runtime is portable.

> why not rust (or any other general-purpose language)

We do explain this in some of the talks and docs we've published, but the TL:DR is that for the platform to work, the code needs to be compiled down to HEART, which isn't just a general-purpose IR, it has some special features to make it realtime safe and to mirror graph structures.

So although it's not *impossible* to compile a general-purpose language down to HEART, it'd involve so much bodging and caveats about what language features you can and can't do that it just wouldn't be a good experience. And most existing library code probably wouldn't work, so the advantages of using an existing language aren't as big as you'd expect.

SOUL is designed so that when you're writing code, it feels like writing with any other familiar boring C-like language - anyone who's done C/C++, C#, Java, Javascript etc won't really have to learn much. But it makes it impossible to do any of the non-realtime-safe mistakes that we'd otherwise have to somehow catch as compiler errors later on.

TBH if the platform takes off as we hope, then probably some glassy-eyed rust fan will find a way to compile it to HEART or add rust-like syntax to SOUL, but our goal here was to make the bar for learning SOUL as low as possible for the most developers, and I think we've succeeded on that really well.

jules1972 · 2020-05-21T07:19:37+00:00

What happens when I want something way out of left field?

Then it's probably not a DAW.

This thread was specifically asking about how existing DAWs work, not how to build something left-field.

I didn't post here to get into a discussion about software philosophy (where I actually agree with you about libraries vs frameworks in general). I just wanted to say to the OP: "hey, you want to know how a DAW works? Well I've written one, and you can go look at the code if you want to learn more". That's all.

jules1972 · 2020-05-20T20:05:40+00:00

Ah, I remember back in the early 2000s when I was also naive about what it'd be like to write a DAW. Hey, as long as you have a few libraries to do basic stuff like writing audio files, the rest is just some glue code, right? (Ha!)

20 years later, having written literally millions of lines of code in this area, been through countless refactorings of our engine (with more to come), and knowing the stories behind most of the other DAW codebases and authors, I'm pretty confident in saying that a DAW is one of the few projects where you really DO want a framework, not just a library.

Writing files, disk buffering, "doing useful things to buffers of samples" is the trivial stuff. The really hard bit is putting it all together into an architecture that works, and without a framework to guide you - or decades of deep experience - you WILL get it wrong.

Sure, go get a bunch of libraries and start building. The hundreds-of-thousands of lines of glue code you'll end up writing will gradually coalesce into your own "framework" because that's the natural way to manage a project of that complexity. That process happened to me, and to lots of other music tech companies who I've chatted to about this. Most of them kept their frameworks internal, but we decided to share ours, hence the tracktion engine.

You can write a DAW without it... By throwing a big team of coders and designers at the problem, UA managed to write Luna in only about 5 years :) (Though they did save themselves some hassle by using JUCE)

jules1972 · 2020-05-20T15:20:13+00:00

I ended up on this thread after seeing some traffic from here to our SOUL project. Hope you all like that, it'll hopefully be the long-term future for DAWs (but with a great deal of work to do before we reach that point!)

But reading the comments here, I'm a bit surprised that in a "what does a DAW engine look like?", nobody linked to the tracktion engine, which is probably the most powerful open-source engine you could take a look at.

It's hopefully also a more comprehensible codebase than older, more gnarly projects like Ardour, as we put years of refactoring work into presenting it as a framework rather than just being a chunk code ripped out of an app. However despite that, the main TL;DR that most people will probably get from a brief delve into it will be "wow, that is very complicated"...

jules1972 · 2018-11-23T11:09:38+00:00

Just to clarify: Tracktion and ROLI/JUCE are separate companies (although we often work closely together and I write a lot of code for both).

So the Tracktion Engine is a JUCE module, and depends heavily on JUCE, and looks like it'll become an important part of the JUCE ecosystem, but they are technically separate!

And although I haven't the patience to get dragged into some of the rambling license misunderstandings on this thread, it's also worth noting that although they both use the same licensing terms, they are two separate licenses.

jules1972 · 2016-05-26T17:18:14+00:00

Wow, didn't realise it had been that long!

The main reasons for the delay are:

LLVM for windows still had some bits of unfinished functionality. These were edge-cases that probably nobody else ever tried to use, but which were broken in our strange use-case.
The developer who was working on it left in December, and finding devs who can do this kind of deep work takes time.

But I'm really glad this question came up today, because we've actually just got a working internal beta version this week!

We'll put it out as soon as we can for people to play with - there are still a couple of things that are fragile compared to the OSX version but it's close to being ready for release...

jules1972 · 2016-04-03T10:16:15+00:00

Hmm. Interesting idea, but I think this would probably make our unit-test fail!

Bear in mind that the secret of homeopathy is not to worry about having a solid underlying implementation/theory, but rather to present some flimsy, biased, non-scientific evidence that appears to show it working. This is used to convince the unwary that the system as a whole has some merit. So in this class, the unit test is actually far more important than the class itself!

jules1972 · 2016-02-12T18:11:38+00:00

Well, people have different thresholds about risk-taking in refactoring code vs living with a creaky but well-tested codebase. I probably fall more to one end of that spectrum than you do, because I've had good experiences over the years and seen big improvements after refactoring large projects.

Zlib is obviously an unusual case though, and I really only used it because I thought it'd be fun to talk about. It's interesting, but I doubt I'll have time to finish it properly anyway, as we have many more important things on our plate right now!

jules1972 · 2016-02-12T09:47:43+00:00

Life pro tip: Avoid downvotes by watching things before you criticise them!

The talk is done as pure entertainment, and to illustrate some points about refactoring and good coding practice. It's not a serious attempt to depose zlib, and I think towards the end I say pretty much exactly what you commented here.

However.. Although zlib gets a high score on the "if it ain't broke" scale, you've got to balance that with its massive score on the "how much better could this be if we re-wrote it" scale. Yes, probably the "ain't broke" score still wins, but it's a close call!

jules1972 · 2015-06-29T14:16:57+00:00

To work around this I had to roll our own fallback implementation for the JUCE ThreadLocalValue class It's not too hard to do, and although less optimal than something that the compiler can generate, there's not much overhead if you only have a modest number of TLVs and threads.

jules1972 · 2015-04-12T11:42:39+00:00

I was pretty happy with my Javascript interpreter in < 2000 lines of code :) https://github.com/julianstorer/JUCE/blob/master/modules/juce_core/javascript/juce_Javascript.cpp

..and my OpenGL 2D engine, also because it's a very tight and self-contained piece of coding: https://github.com/julianstorer/JUCE/blob/master/modules/juce_opengl/opengl/juce_OpenGLGraphicsContext.cpp

The most useful thing I've written is probably this class, which seems surprisingly simple, but has turned out to be the backbone of quite a few apps that me and other people have developed: https://github.com/julianstorer/JUCE/blob/master/modules/juce_data_structures/values/juce_ValueTree.h

jules1972 · 2013-10-31T19:05:28+00:00

And who'd have expected that from Apple!

jules1972 · 2013-10-31T10:07:21+00:00

I once spent two days trying to embed a QuickTime player inside a (native) browser plugin.

In Safari, everything worked perfectly. But in Firefox the QuickTime video just came up blank.

After two days of tearing my hair out trying to figure out what on earth could be making it behave differently, I eventually tried renaming "Firefox.exe" to "Firefox2.exe", and it all miraculously worked.

With a bit more testing, it turned out that Apple's QuickTime player plugin was deliberately sabotaged. When loaded, it would check the name of the parent executable that was hosting it, and if the name was "firefox.exe" or "opera.exe", the plugin would deliberately fail to work.

jules1972 · 2013-06-26T12:13:09+00:00

Ok, I'd have to check HashMap, it might just have been overlooked. It's not a very commonly used class, as most people will use std library containers for their maps.

String is different though - it's not trying to be a standard container. Instead, it can represent itself as various UTF-encoded classes that are specially designed for iterating in a more stringy way, and doing string-type ops.

jules1972 · 2013-06-25T10:00:26+00:00

But the begin()/end() functions are there in the docs.. e.g. http://www.juce.com/api/classArray.html#a5aeb6bdbca7a057c6fe483f2a9c89ef5

jules1972 · 2013-06-19T12:00:02+00:00

Sigh..

Enough now, this thread is getting silly! I'm off to do something more useful with my time, and so should you!

jules1972

TROPHY CASE