You can use TransportControl::isPlayContextActive() to determine if there is an audio graph built and attached to the audio device (for playback)
You can call Edit::restartPlayback() but to be honest you shouldn’t really have to (see 3)
All of the audio graph rebuilding for things that Tracktion Engine knows about is handled automatically internally. You shouldn’t have to call restart yourself at all if you’re using the stock Engine. The only time I can think that you’d need to call it manually was if you have some custom behaviour on top that indirectly affects the way the audio graph would be generated, but I’m struggling to think of a single concrete example…
If you want a deeper look at how this is handled internally take a look at Edit::TreeWatcher in tracktion_Edit.cpp
I was really looking for general information—things to know and keep in mind when dealing with the audio graph.
The only specific problem I’m having at the moment is with recording one track while playing back from another. The audio on the second track appears to be phase canceled by the playback track.
So, I have two tracks. Track one is set to input one, and Track two is set to input two.
I arm Track one and record some audio.
Then, I disarm Track one, and arm Track two. And, I “rewind” the playhead back to the start of the Track one clip.
So, now I am hearing Track one as I record track two.
The Track two sound is audibly affected. It shows in the waveform thumbnail. And when the Track two clip is played back, it has been affected by the Track one clip.
This is reproducible in the Recording Demo.
What might cause this? And, how do you properly prepare the audio graph for recording new tracks as you playback existing ones?
That sounds odd. Can I ask a bit more about your setup? What is your input signal? I wouldn’t expect any phase cancellation, even on playback unless your signal was nearly identical during both recording passes…
Are you perhaps using some kind of loop-back on your audio device and the output from your first track is being mixed in to the input of your second track?
Are you calling TransportControl::stop before doing your rewind? That’s needed to “commit” the clips to the Edit.
I am testing on my development laptop, which is a Windows 10 computer. I simply record through the builtin microphone while coding. I can try it in my studio setup later.
Yes, I am calling TransportControl::stop. In fact, my Rewind button is disabled unless Stop is pressed first.
Please note, the issue is reproducible in the Recording Demo. And, I have tried a few more things. I have found that if I Mute the first track while recording the second track, the cancellation does not occur.
So, again, if I record Track one and Track two together, everything is fine. But, if I record only Track one, return the playhead to the beginning of the Track one clip, and now record Track two, while listening to Track one, the cancellation occurs. If Track One is Muted, it does not occur.
It will be a few hours until I can test on my studio equipment. But I will do that test so that hardware/driver idiosyncrasies can be ruled out.
And, in the meantime, perhaps someone can try the above procedure with the Recording Demo?
So, on my studio setup, everything works correctly. I tried several combinations, and all worked as expected. So, this definitely points to some odd behavior on my development system.
Perhaps the best we can learn from this is to beware what you are testing on (Acer laptop, Realtek sound). No matter how generic, it may still not work as expected!