Hi @dave96 I’m returning to this project after some time away. After updating TracktionEngine, I’m finding I still have to manually call timerCallback on WaveAudioClips in order to render mp3 files, which requires hacking the TE source to make AudioClipBase publicly inherit from juce::Timer.
Is this something you would still consider fixing? Or perhaps there’s a fix that I missed in the last 8 months? Many thanks for looking into it.
@dave96 do you think this update could still arrive at some point? Please let me know so I can plan accordingly! Thank you!
Yes, I’ll take a look now. Remind me of the problem so I can do the appropriate fix…
If you put a breakpoint in AudioClipBase::getPlaybackFile when the rendering audio graph (from createNodeForEdit) is created, if the file that gets returned a wav proxy or the original mp3?
I think it should just be that the proxy file needs to be returned here, then the rendering process will wait for it to be created. Assuming that the message thread is unblocked? Or is that the problem?
I just tested again with the most recent commit to the tracktion_engine master branch.
I can confirm that AudioClipBase::getPlayBackFile is returning a proxy. The process is just hanging when the edit includes an mp3 file. Presumably this means that the message thread is blocked?
Yes, looking at your stack trace you’re blocking the message thread. There’s lots of stuff that happens async so it would probably work fine if you just didn’t block the message thread.
This is usually done with a progress window that’s modal but non-blocking or holding a handle to the task in your application class if it’s a CLI (take a look at the pluginval CLI for an example of how to do this).
That’s probably easier than trying to guess all the timer/message callbacks that need to happen before a render can take place.
