Project info and why not to use it atm

Tracktion Engine
1

@dave96 You had metioned in Tracktion Engine now Open Source! - #87 by dave96 about not using Project, do you think you could expand on that a bit?

One thing I would say (and I’ll add some documentation to this end soon) is that you should avoid using Project if possible, mainly because it’s not really needed and you can do everything now with an Edit and relative paths (this wasn’t possible until a few weeks ago).
Project (and ProjectManager ) is on my list to give a big ValueTree-based overhaul to which may change the API so probably not a good idea to fully rely on that right now.

The Edit and relative paths part.

2

I don’t want to complicate things by saying how things used to be done so try and ignore the following but if it will help understanding…

Until recently, every AUDIOCLIP had a source property which was a ProjectItemID (which looked something like af243/bc72a where the first half was the Project ID and the second the Item ID.

Audio files were then looked up by finding the tracktion_engine::Project from the Project ID part and then the tracktion_engine::ProjectItem from the Item ID part. The source of this tracktion_engine::ProjectItem was then used for the source of the AUDIOCLIP.

Now we’ve simplified this process a lot by introducing the tracktion_engine::SourceFileReference class. This can work as above or it can hold an absolute or relative path.

If it’s a relative path then it uses the Edit's filePathResolver to return resolve the path to a juce::File object. That is then used for the AUDIOCLIP's playback.

The one thing you might come up agains here is the because Edit doesn’t have any notion of a “file” (it can be running purely in memory), it needs a way of resolving relative paths. This is what Edit::editFileRetriever is for. For Waveform, we use the default implementation which looks for a tracktion_engine::ProjectItem associated with it, but you can set this to something else if you like, whatever suits the way your app deals with files.

For example, if you know the location of your Edit file on disk and all other files are relative to that, after you’ve constructed it simply do something along the lines of:

edit.editFileRetriever = [editFile] { return editFile; };

I hope this helps.

3 Likes
3

Yes, thanks that makes complete sense.

So basically you could create a zip archive that it’s root is an Edit serialization, place all dependencies in that directory and with the one line above, everything is still hooked up.

I haven’t really used(more then getting to know it) Tracktion or Waveform the DAW as of yet but, do you ever serialize the audio inside an Edit file?

4

We do but it uses a proprietary (it’s in the repo) format. However, its old, bloated and clunky.

The approach you mention is what I want to transition to. With that in place archiving will be the following process:
• Consolidate: Copy all external files in to a sibling or child directory of the Edit file
• Optimise: Optionally convert all audio files to compressed formats like flac or ogg. This stage can also remove any sections of audio that are not in use in the Edit
• Archive: Zip, now we have all the files we need, we can simply zip them all up using Gzip or even an uncompressed zip if the above optomise stage is enough

Now you can share that archive around as you like as it contains everything required to unpack it. Un-archiving is a little trickier as you have to assign new IDs to everything but we can add some helpers to do that.

1 Like
5

Nice! Yes, this is great since not all the time you have people using the same samples (app paradigm).

I think this is even more important on mobile as the “projects” are not any where near as large as they are on desktops.

Interestingly enough, I could almost see a Library setup where in an app you intentionally structure things that an app can provide an audio library that all shares the same base, I did this in my app Drum Pad Beats (Shared Library).

Curious, if you optimize for compression with the actual audio files that would then be reloaded, since they are lossy, bringing them back in there is no way to get that data back.

So this is a user’s decision to favor file size verses original raw audio samples?

6

Yeah, if they chose ogg. Flac is lossless though.

1 Like
7

Not completely, because it does not support floating point formats. :wink: The WavPack lossless codec supports floating point, but of course adding that into the supported file formats would be yet another headache…

1 Like
8

So theoretically what would happen? So is it converting floats to integers?

9

Yeah with FLAC the data needs to be converted to integer first. (Or it does the conversion itself if given float data, I don’t remember the details.)

1 Like
10

Yeah, maybe, I guess it depends what WAV format you’re saving to though. That’s usually 16 or 24-bit int so you have the float conversion there anyway.

1 Like