I’ve been reading the Tracktion code with the idea of making a simple “destructive” audio editor: i.e., effects and edits appear permanent, save for undo/redo that should work as expected until closing the project. Think soundforge rather than a DAW.
As I see it I can still use the Edit project structure, and any clip additions on top of the original file(s) should be stored as separate audio clips, using ”layering/comping” on the file in the memory model, under the hood. In the UI the visualization can look like a single clip. So each user action could create a new clip in this tree, and layer it on top of the underlying data. (When exiting and throwing away undo history, to reduce file size, the clips could optionally be “consolidated”/”flattened”).
Actions that should be supported:
Applying “destructive” effects: A plugin applied on a selected region would render into a file using the underlying data, and be placed on top, filling the selected region. Sounds very doable with Tracktion.
Moving sections around, joining, slicing: doesn’t have to be destructive until exit-and-save (or not even then), it’s just a question of not drawing the seams.
Zooming-in enough to “paint in” individual samples: Each paint stroke/click, could result in a tiny clip. Many such consecutive actions would add up, but maybe nothing Tracktion can’t handle? IF the tiny clip can be in-memory, then maybe with additional work in the undo/redo command for the stroke action, the need for new clips on each stroke for a region isn’t needed, only the first one? Otherwise this is probably still workable.
My questions:
1: I looked at Clip’s addTake(…), but that doesn’t seem to be what I need for the “audio clip tree”. But it appears an Edit can contain sub-edits? In that case each “audio-file” can be such a sub-edit, in the root project Edit, right?
2: For the “painting-in” of samples, does Tracktion support in-memory only clips (for small enough samples), and custom undo/redo commands for altering these? Alternatively, that the Edit-tree is allowed to become a bit deep with a lot of overlapping clips (for the undo/redo)?
I tried to keep it brief, I hope this makes sense, and I hope there’s nothing in Tracktion that would keep the above for working!
You might be able to mimic something like that by layering clips on top of each other but the per-sample editing is going to be difficult I think.
For that, you really want a clip to play back from a section of memory and that’s not really something we have support for.
We do support loading of audio files in to memory to be read (faster than streamed from disk) but that’s a read-only operation.
I do wonder if you could do something like use a memory-mapped file with read-write properties. If you make an edit to the file it would be propagated to the memory but you’d have to work hard to keep your UI update to the memory pool (drawing audio thumbnails usually involves many layers of caching for speed).
That might work for single sample edits but it will be difficult if adding multiple clips etc. as they’d reference different files/memory. But maybe you’re ok with multiple layers whilst the app is open?
Remember any effects that have a tail or latency will be affected by samples before them and effect many samples after the region they’re applied to.
I think the worst case scenario is still workable for paint-in, of each action resulting in a new clip. As long as it’s implemented somehow. These paint-in edits are such tiny clips: I envision you have to zoom-in deep enough to see individual samples, or you’re not allowed to even do it.
With that in mind I’m even OK with the project folder being filled with them until consolidation/cleanup happens.
And each “paint” action on the UI I’m OK with resulting in creating an entirely new Clip replacing the previous “painted clip”, alt. layering on top. And undo/redo can swap them or remove/re-add the topmost.
What’s most important is that playback is efficient enough to work under normal “low latency” settings with e.g. an ASIO card.
From your reply it seems that there’s nothing in the edits-in-edit model that would keep me from having a moderately deep “tree” of clips that way, right @dave96?
Then I might start sketching on building this in code manually as a POC to see how it all could work.
