I have discovered this issue on my app but I was able to reproduce it in the juce audio plugins host.
I have created a dummy class that implements juce::AudioPlayHead and I have set it to the graph in the PluginGraph Constructor.
class MyAudioPlayHead : public AudioPlayHead
static MyAudioPlayHead& get()
static MyAudioPlayHead instance;
virtual bool getCurrentPosition (CurrentPositionInfo& result) override
memset(&result, 0, sizeof(CurrentPositionInfo));
result.timeSigDenominator = 4;
result.timeSigDenominator = 4;
result.bpm = 120;
PluginGraph::PluginGraph (AudioPluginFormatManager& fm, KnownPluginList& kpl)
: FileBasedDocument (getFilenameSuffix(),
“Load a graph”,
“Save a graph”),
Nothing fancy and as expected the getCurrentPosition is constantly called when I add a plug-in that obviously queries it. But if I go to audio settings and change the sample rate or the buffer size which I assume will reset the plug-in by calling releaseResources and prepareToPlay the getCurrentPosition is not called anymore (In my app, I tried calling the setAudioPlayHead everytime just before the prepareToPlay but same problem)
This is happening in MAC and for audio units only. I have tried VST3 (again in MAC) and they seem to work as expected. I have tried two different audio unit plug-ins (one being Kontakt and the other one a simple guitar instrument) and they both had the same problem.
The further I got was the method
static OSStatus getBeatAndTempoCallback ( void * hostRef, Float64* outCurrentBeat, Float64* outCurrentTempo)
return static_cast <AudioUnitPluginInstance*> (hostRef)->getBeatAndTempo (outCurrentBeat, outCurrentTempo);
which is obvisouly not called after sample rate/buffer size change
Looking forward to understand this…
I haven’t looked at the exact definition of the
CurrentPositionInfo definition, but I think the memset call is not a good idea.
The struct should be initialised correctly by default by the caller and you only set the information you have.
About the actual problem, you might haver to re-add the AudioIODeviceCallback. The AudioDeviceManager is a ChangeBroadcaster, maybe you can catch that callback and fix it there (which makes sense, the device could also have changed)
N.B. please add three back-ticks around your code for code formatting
I will keep the focus of this conversation to the actual problem:
As I explained, this looked like a bug in audio units as VST3 work fine. Your suggestion was not clear to me at all so I was forced to investigate myself further. To my understanding, releaseResources is removing some callbacks (not the AudioIODeviceCallback). The solution which fixes my problem was to
at the very early of the method prepareToPlay() in the juce_AudioUnitPluginFormat.
I am not convinced that this is the best solution but it will do for me (and maybe others). I do hope that you will provide a better fix as you know the code there a lot better.
Thanks for your time
createPluginCallbacks() was changed to
setPluginCallbacks() a few minor versions ago.
I can’t reproduce the issue on the current
develop branch, so this could be something that was fixed recently.
Can you check if there is still an issue on
I used the following patch that changes AudioPluginHost and AudioPluginExample so that AudioPluginExample is displaying the playhead position. It’s pretty much in line with what you suggested, but there could be a subtle difference.
playhead-test.patch (8.5 KB)
Thanks for looking further into the issue.
I just looked at the juce_AudioUnitPluginFormat.mm in your current repository and I can see that there is a fix similar to mine. setPluginCallbacks() is called at the very early of prepareToPlay.
I guess that is why you cannot reproduce it and I am pretty sure as you have suggested that this is indeed fixed in the develop branch.
You may safely consider this issue solved. Thanks again for your time