@oli1 Oops, you’re right! Fixing this and making a couple of additional changes has proved highly instructive:
Just adding the missing addChangeListener() call isn’t enough (of course), because Logic Pro X calls the processor’s audioWorkgroupContextChanged() function before creating the editor. I had to add the line changeListenerCallback(nullptr) at the end of the editor constructor to ensure the display message got updated.
To test the actual ChangeListener callback mechanism, I tried changing the current audio output device in Logic Pro X’s settings. My plug-in’s editor closed, and when I re-opened it, I again saw that exactly one audioWorkgroupContextChanged() call had occurred.
I suspected that Logic had quietly re-instantiated the plug-in, rather than making a second call to audioWorkgroupContextChanged() on the original instance, so I added code (see the GitHub repo) to detect this. Sure enough, that’s exactly what happened.
Embarrassed though I may be for forgetting the ChangeListener connection, I’m delighted that
I have confirmation that Logic is indeed calling audioWorkgroupContextChanged() on my Audio-Unit plug-ins.
I have learned something new about how Logic actually handles audio-device changes, and
I now have a working AU test plug-in which I can use to test other plug-in hosting scenarios.
Thanks to your timely help and a bit more digging, this hurdle is behind us. I’ll start a new topic to address other concerns.
Something new has come up. If I put two instances of my MTPlugin test AU plug-in on separate tracks in Logic Pro X, then click back and forth between the tracks to enable one and then the other, AUHostingServiceXPC_arrow will eventually crash with a different error:
The crashing seems to be triggered only when some MIDI has been sent to one of the tracks. I’m scratching my head about this. The plug-in code does virtually nothing, so I’m thinking it might be something in the JUCE AU client code??
@getdunne thanks for reporting. I’ve been looking into this today. I managed to reproduce the issue both with your example plugin and with the MultiOutSynthPlugin Demo. After performing a bisect I was able to confirm the issue started when the Audio Workgroup commit was added. I’ve tracked down the issue but it’s not completely clear to me yet what the right solution is so I’ll likely pick this up again next week. It looks like this is only impacting software instruments (although I haven’t tested all the different AU plugin types).
Well @getdunne I got to the bottom of the issue you shared but in the process came across another issue that was intermittent and much harder to track down! I think I’ve got to the bottom of both issues and I have something up for review. I’ll try to keep you posted but hopefully we can have something merged soon.
Any news on this ?
I have report of crashes in
Thread 56 Crashed:: com.apple.audio.IOThread.client
0 libdispatch.dylib 0x18cd32e24 _os_object_retain + 64
1 AudioToolboxCore 0x18eb695b0 RenderContextChangeGenerator::checkChange() + 28
2 AudioToolboxCore 0x18ed522e8 AudioUnitRender + 692