Project info and why not to use it atm

Tracktion Engine
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