Daw development question

Hello,

I am developping a clip based daw, something between NI Maschine and Ableton Live on my spare time, not for a professional purpose.

I have some questions about Juce and about audio summing that I can’t answer yet. With a little help, I could go further… My questions are simple to list:

  • How Juce can help me with this project ?

The SDK provide “Application”, but does it mean something like a Daw or just plugins ?

  • Did someone know a ‘book’ (pdf, paper, html,…) documentation/turorial about audio summing ?

I know that the graph approch is needed to achieve properly audio summing, but I didn’t find written documentation/tutorial about it, which could help me (more than this : https://www.youtube.com/watch?v=Mkz908eP_4g) to understand better how I can implemented myself this.

  • Do exist a “C” Library equivalent to Juce ? especially for the graph audio summing part ?

Because I find only audio player library in C, and want to write the engine in C (my favorit programmer langage, and because I want to implement this Daw an a embbeded system in the futur)

Thanks in advance.

Have you considered Tracktion Engine | Tracktion ?

I never used it myself (i don’t know what it is able to do) but it seems to be a sustainable approach.

@nicolasdanet Yes, but since the API is in C++, I try to find something else.
Actually my option is the framework PortAudio (https://www.portaudio.com/) that is a low-level C API, but it didn’t provide graph node for multitracking.

The main issue I have, is specifically the audio graph processing part. If I can’t find suitable documentation/tutorial about it to learn and implement it myself, yeah, I will figure out to write the code in C++ and use the Trackion engine or Juce if it is suitable for my aim.
But at the moment I try to understand the “backend” of audio graph processing, and they will see which SDK I will use to implement it, my own, Tracktion engine or Juce or something else.

I would strongly recommend going JUCE and C++, whether you use the Tracktion engine or develop it yourself. JUCE has a full implementation of audio graphs that is instrumental to building a DAW.

I built one myself and it was a huge task in itself using JUCE. Can’t imagine building it in C from scratch.

Traction Engine represents many man years of development. You would be hard pressed to reproduce what it can do. Your task would be to learn it and apply it to your needs, but this is far easier than trying to do everything from scratch. They have already figured out many edge cases and ambiguities. You can benefit from all of that work.

Tracktion Engine is the backbone of Waveform. And many have used it to develop their own DAWs, including me.

It will be a steep learning curve, but a rewarding experience.

1 Like

Thanks for advice.
I will dig it to see if it fit my aim.

This is off-topic, but those of you who have used Tracktion to build a DAW - can you share more details about your experience, or maybe provide a link to the product so we can see it? I’m also in the middle of using Tracktion for a project, and besides Waveform it would be great to see the work of the folks that have gone before me, as inspiration and also encouragement that, after all, if you guys can work it out so can we … :wink:

Any chance of more details, Tracktion-devs? @bwall @swar ? Its very interesting!

I haven’t used Tracktion (should have, probably), built it directly from JUCE. It’s a lightweight but complete DAW (audio/MIDI/aux tracks, buses, sends, automation, etc…).

You can find more about it here: Swar Studio - a full-fledged DAW with Bollywood music in mind...

1 Like

@swar What will be interesting, as mention @anon48770766 will be to have the source code + the architecture documentation for learning purpose.
I think, it is what it miss a lot.

Not to blame you, but it is a common things I see a lot, wonderful projects with an indigent developement documentation (Doxygene) or proprietory.

On the subject, Juce looks great if I use it as static library. I will take it for the moment. So, I could learn in the meantime how to do it myself and develop my own library in the futur.

I understand, but this is a proprietary project, not open source.

What kind of details are you after? For something as big as a DAW engine there are endless details :wink:

Your experience, how things went compared with the expectations, what gotcha’s you ran into, what you hope Tracktion will address in the future, what you found fun about using it to build a DAW, etc.

Maybe this is too general a request, but we rarely get much insight into building a DAW with Tracktion around these parts, so it might be interesting to folks to hear your experiences, is all … and certainly if there are maybe more obscure DAW’s out there shipping, using Tracktion, that is also interesting as well.

Sorry, maybe I should have said, I’m the main dev of Tracktion Engine and Waveform so coming at it from a different angle to most users of the framework.

D’oh, of course I should’ve recognized you as the Mr. Tracktion. :slight_smile: - what I have observed in the 6 months since I started learning Tracktion myself, is that there is a need for more details about it as a framework, some of the architecture decisions that were made (and why), how to deal with the various types of updates that can be performed on Edits, etc. - basically just some tutorials on how to build a very basic DAW would be nice to have, just as a starting ground for bigger things … how to wired it up to a GUI, what the expectations are for how that GUI can operate on the Edit, etc.

Of course, were someone to make a very basic open source audio editor with Tracktion, this would go a long way for a lot of folks to learn it … and no, I’m not demanding anyone drop everything and just do this - just a suggestion, really, for what I’d like to have had as a newbie embarking on the adventure to learn to use Tracktion properly …

1 Like

You have a very basic DAW in the examples of Traktion.

Yeah, I hear you. It’s always hard to determine what to add and what to leave out though. The point of the framework is that it’s not tied to any particular UI so it can be whatever you want it to be.

UI code gets really big fast. If you take a look at the recording demo, MIDI playback demo (or a sneak peak at the new clip launcher demo in the feature/launcher branch) you should see what I mean. None of these even have property/inspector panels or deal with multiple selection etc. they’re just the most concise way we could demo some of the audio capabilities of the Engine.

I would like to do more tutorials but without them being real code (and hence compilable by CI), they get out of date really quickly and that’s less helpful than not having them. Our aim is to make the demos as simple to follow as possible to try and explain the main concepts in the Engine.

I’m always keen to know the things people just get “stuck” on though. Sometime we can add some simple assertions or docs to help out with this.

As for threading, we basically operate on the the model that everything is message-thread only unless specified otherwise. There are some places (like rendering) where you can provide your own threads to run things on or callbacks that obviously happen in the audio thread (e.g. Plugin subclasses) but again, there should be lots of assertions to catch mis-use so I’ve never thought it would come as a big surprise to people. Is that the kind of stumbling block you’ve seen?

At first, my DAW essentially developed from the Midi Recording Demo included with Tracktion Engine. Then I added capabilities from the other demos, such as audio recording. As time went by, I added additional features and capabilities, such as automation.

Eventually, as I became more familiar with the inner workings of Tracktion Engine, I refactored the code to my programming style such that it now bears only a loose resemblance to the Demo code.

The biggest “gotcha” in the whole project is the amount of time it will take to wrap your head around everything. But even so, it still is far easier than starting from scratch.

Once you are in the Tracktion Engine ecosystem you have professionally maintained backend code that is updated every few weeks! Remember, Tracktion Engine is the backend for Waveform which is a popular DAW. So, the developers are constantly striving to keep it up-to-date and bug free, which you would otherwise have to do yourself!

3 Likes

I’m not trying to be facetious but can I ask why people want to build a DAW in the traditional sense (i.e. one with classic tracks/clips/plugins/automation in the UI, not an app that is a DAW behind the scenes but has a different UI or UX)?

There’s two reasons I ask:

  1. As an engine developer, it would help me know our potential customer base more so we can serve them better
  2. As a DAW developer, it’s just such a monumental task to undertake in a ridiculously competitive market that unless there’s some specific business case for it, seems like an absolute black hole of resources

It always worries me a bit when I hear people on the forums ask “I want to write a DAW, point me in the right direction”. I just hope they’ve thought about it a bit before sinking loads of time in to it. It’s not fun, trust me :wink:

Incidentally, I’ll be speaking about some of these things (and more) at ADC this year:

9 Likes

I would have absolutely loved to use Tracktion Engine/Graph instead of approaching this from scratch…But I have the special case need that I have to be able to use Clap plugins with all/most of the new features they support, which is not possible using the Tracktion Engine and was difficult enough with just the Graph part too that I am now looking into doing also the audio graph part myself. (Which I very preliminarily got working today after a few hours of work. It’s obviously not perfect in any sense, but already works pretty well for my immediate goals.)

If I speculate on behalf of other people, perhaps they feel like the additional license fee of Tracktion Engine just doesn’t suit them. Maybe they have free/very cheap developer hours to put into implementing a DAW engine from scratch. :man_shrugging:

Summing audio signals is literally just that : you sum, that is add, together different audio signals. You don’t necessarily even need a separate audio graph system for that, for example if your audio routing architecture is relatively simple. In practice, I have come to the conclusion that having some kind of explicit graph to deal with the signals routing is better, though.