Time Warp Temp File Woes?

I’m not sure what is causing this, but I’m trying to create a basic edit + track + wave audio clip while calling setWarpTime (true), and I’m hitting the only assertion in AudioFile::deleteFile where it can’t delete the temp file.

Any ideas?

This can be demonstrated by running the PitchAndTimeDemo pip and adding clip->setWarpTime (true); just after the line clip->setAutoPitch (false);.

Is it possible that AudioFile::deleteFile should look like this instead?

bool AudioFile::deleteFile() const
{
    CRASH_TRACER

    auto& afm = engine->getAudioFileManager();
    afm.checkFileForChangesAsync (*this);
    afm.releaseFile (*this);

    if (file.existsAsFile())
        return file.deleteFile();

    return true;
}

Does that change actually work for you? Looking at the juce::File docs:

        @returns    true if the file has been successfully deleted (or if it didn't exist to
                    begin with).

So the check to see if it exists shouldn’t be required…

Is something else holding on to the file handle like an audio thumbnail?
And I assume this is on Windows? Deleting files is a real pain there as all file handles need to be closed for the operation to succeed.

Hm ok… based on those docs, I think what you’re saying about file handles still being in use seems likely. And yeah, I’m testing on Windows.

If you make the change I suggested above to the PitchAndTimeDemo pip, do you encounter the same thing?

The situation is getting stranger the more I try to use this feature in the provided PIP. Now I’m hitting, albeit sporadically, this assertion (on Win10 btw):

void Clip::setCurrentSourceFile (const juce::File& f)
{
    if (currentSourceFile != f)
    {
        jassert (f.existsAsFile());

What I’m thinking is happening is that the cached temp file somehow gets out of sync with what the audio clip recognises, and for some reason that cached file is gone before it gets set to the clip.

The assert in Clip::setCurrentSourceFile is probably incorrect and can be ignored/removed. I think it’s because the source file is being set to a proxy file which doesn’t exist yet. The assertion was probably added by mistake when debugging a different part of the library.

I did try adding the clip->setWarpTime (true); but I don’t get any assertions when changing the pitch/tempo or loading a new file. Are you sure you haven’t made any other changes to the project?

Absolutely. Nothing to JUCE, TE, nor the PIP beyond what I’ve described. Latest tip of develop for JUCE and TE.

Does the proxy get generated regardless, even when not explicitly setting setUsesProxy (true); on the clip?

true is the default. The time-stretching won’t and tempo syncing won’t work without that.

1 Like

Please try closing the app via the normal exit button: I hit the assertion mentioned regularly with this method.

Nope, still closes cleanly.
Can I check what branch you’re on? There might have been some recent changes? I use the tracktion_graph branch most of the time but develop is pretty close to that.

develop for JUCE and TE.

Can you try the tracktion_graph branch?

I’ve run this many times now and it always seems to succeed in AudioFile::deleteFile().
What is the call stack when you hit the assertion? I.e. what is causing the deletion?

When trying the tracktion_graph branch, the AudioFile::deleteFile assertion does NOT go away; it’s hit on app shutdown in my app.

And the assertion in Clip::setCurrentSourceFile gets hit consistently now:

Ok, looking at the stack trace it looks like it might still be rendering the proxy file when you close down and that’s why I wasn’t seeing it (I was only trying with very short samples than render in a couple of seconds).

It’s also important to note that this PitchAndTime demo was just a quick example to show the basics of matching an audio file to a pitch and tempo so any changes to the code could well throw up some unexpected consequences such as this.

I’ll try and take a look at this tomorrow when I’m back at work.

So I spent a bit of time trying to replicate this today with some longer MP3 files and I still can’t get it to hit the deleteFile assertion. (Using the tip of the tracktion_graph with only the clip->setWarpTime(true); line added).

Are you sure there isn’t anything else going on here? I notice in your stack trace you’ve redacted it which would indicate you’re not actually using the PitchAndTime PIP but your own app?

If I were to guess it looks like you’re closing the app whilst it’s still rendering some kind of proxy (there are several reasons this could be e.g. time-stretching or warp time) and that’s trying to delete the file while you have some handles open to the file somewhere else. That could be because you’re trying to draw it without using the tracktion_engine::SmartThumbnail class?

The only other thing I can think to try is dig in to the Windows File::deleteFile and get the reason the delete is failing. That might have some more information but will probably be because the file is open somewhere. If it is that, then maybe add some logging to juce::FileInputStream to track open/closes to the handles and see if there are any still in use by the time the deleteFile method is called?