I’m looking for more information on the use of proxies with time stretched clips. I would like to able to change the length of a time stretched clip without recreating the proxy.
Here’s the example scenario (and how I understand it):
I add a 3 minute wave audio clip to my track, I change the bmp of my project to 120 to 100. Now Tracktion Engine creates a proxy of the audio clip that’s now 3.6 minutes long, great. Now I decide I don’t want the last 5 or so seconds of the track (there’s some empty audio maybe) and now in tracktion_Clip.cpp Clip::valueTreePropertyChanged sees that the id evaluated to IDs::length and calls AudioBaseClip::changed() which then dumps the current proxy and then creates a new proxy that’s 3.55 minutes long. This new proxy has the same bpm so its first 3.55 minutes sound identical to the first 3.6 minutes of the original proxy, the new proxy is just shorter.
Does it sound like I’ve understood the behaviour of the engine properly? Is it possible to change the length property of the AUDIOCLIP without triggering the creation of a new proxy?
No, that’s not really possible. The time-stretched proxy is basically a completely flattened version of that clip.
I agree in your example it sounds trivial to not regenerate it but it imagine if you expanded the clip length, you’d then have an extra 5s that you would need to render.
It gets very complicated very quickly to determine what parts of the proxy file relate to what parts of the timeline (remember the tempo chan be constantly changing) if its not just a 1:1 mapping.
I think you probably want to just not use the proxy right?
In v3 time-stretching is performed on a background thread just slightly ahead of the playback cursor. Whilst not quite as efficient as using a proxy (which has basically zero overhead once created) we’ve found in Waveform this gives the perfect mix of usability (not having to constantly generate proxies whilst editing) and performance (as the time-stretching doesn’t happen on the audio thread).
Just developing my understanding here, how many proxy files are there, and what are they made of? I was working under the assumption that there was (optionally) a proxy file for each audio/midi clip and that they’re a wav file at some reduced bit rate.
Based on these assumptions, if I’m shortening the playback of a proxy I should be able to ask for the first 95% of the file to be played just like a clip without a proxy. I take it the length property of the Audio clip is wired in pretty deeply into the proxy logic.
I’m honestly not sure if I want to use proxies here or not. It’s unclear to me exactly when I’m getting performance improvements and how great they are. It would be nice to understand the pros and cons of this system.
That’s correct. But IIRC they’re 32-bit float wavs so no need to do the integer conversion when reading from them.
Yes, it creates a hash of everything that could affect the proxy generation and length is one of those.
It’s a bit difficult to say without measuring. It will also largely depend on what OS you’re using (desktop vs. mobile), how many cores it has (including the ratio of P/E cores) and the real-time utilisation of the session.
Basically, creating a proxy and then reading from it will be the fastest way to play back the clip in real-time. But you run in to the problem’s you’ve seen when editing the clip. You might be able to work around it when changing the end, but not when changing the start etc. They’re also not really viable for places where clips can be started or stopped at any point e.g. in the clip launcher. That’s why we spent so much time getting the real-time time-stretching working well in v3 and tbh, I would use that as the default these days and only create a proxy if a clip isn’t going to be edited for a long time.
MIDI proxies don’t really suffer from most of the drawbacks mentioned above for audio so they can largely be ignored. The one place they do make a big difference is in the clip launcher (for the same reasons) so I would always use them there, or if you’re looping MIDI clips for an extremely long duration (where proxy generation could take some time).
