AudioProcessorGraph::prepareToPlay Inconsistent in Ableton

Hey All,

I have yet another question about the AudioProcessorGraph.

I’m on the newest version of Ableton, and I’m finding that offline rendering is only sync updating the graph some of the time.

In the prepare to play I added some std::cout:

void AudioProcessorGraph::prepareToPlay (double sampleRate, int estimatedSamplesPerBlock)
{
    setRateAndBufferSizeDetails (sampleRate, estimatedSamplesPerBlock);
    clearRenderingSequence();

    if (isNonRealtime() && MessageManager::getInstance()->isThisTheMessageThread()) {
        handleAsyncUpdate();
        std::cout << "TRIGGERING GRAPH BUILD SYNC" << std::endl;
    } else {
        std::cout << "TRIGGERING GRAPH BUILD ASYNC" << std::endl;
        triggerAsyncUpdate();
    }
}

And what I’m seeing in Ableton is something like this when freezing / flattening & reversing the process to trigger it multiple times:

**IS NON REALTIME: 1**
**IS THE MESSAGE THREAD: 0**
**TRIGGERING GRAPH BUILD ASYNC**
**IS NON REALTIME: 0**
**IS THE MESSAGE THREAD: 0**
**TRIGGERING GRAPH BUILD ASYNC**
**IS NON REALTIME: 1**
**IS THE MESSAGE THREAD: 1**
**TRIGGERING GRAPH BUILD SYNC**
**IS NON REALTIME: 0**
**IS THE MESSAGE THREAD: 0**
**TRIGGERING GRAPH BUILD ASYNC**
**IS NON REALTIME: 1**
**IS THE MESSAGE THREAD: 0**
**TRIGGERING GRAPH BUILD ASYNC**
**IS NON REALTIME: 0**
**IS THE MESSAGE THREAD: 0**
**TRIGGERING GRAPH BUILD ASYNC**

What I would expect to see is:

**IS NON REALTIME: 1**
**IS THE MESSAGE THREAD: 1**
**TRIGGERING GRAPH BUILD SYNC**
**IS NON REALTIME: 0**
**IS THE MESSAGE THREAD: 0**
**TRIGGERING GRAPH BUILD ASYNC**

Everytime.

So my question, is this check for: MessageManager::getInstance()->isThisTheMessageThread() really necessary?

Isn’t it safe to assume that if we’re not realtime, we always just want it to sync update the graph on a prepareToPlay? I mean there’s no audio streaming & things are inaudible, so I’m wondering if it’s safe to remove this code to solve the problem or if this is solving other issues I may not be aware of.

Also, the impact of this is some dry audio at the start of an offline render.

Thanks,

J

Seems to remove the thread check causes issues w/ the other message thread locks in the class… If I remove the MML from buildRenderingSequence it appears to be solved, also I’m unsure why we’d need to obtain the MML if this is always theoretically being called from the Message thread.

hmmmmmm