The Plugin Host does crash at "processor->process (data);", but nothing's jumping out in the JUCE code for me right now. Seems like you would need to get in touch with FabFilter and see if they could debug; maybe they can offer some clues.
From the fabfilter guys:
When Pro-Q 2 receives a MIDI message in the processor, it notifies the controller by sending a parameter change via the host.
It does so by calling data.outputParameterChanges -> addParameterData() to create a new parameter queue if needed, and then it calls addPoint() on the queue.
The problem is that addParameterData() returns NULL in the test host, so the call to addPoint() crashes.
Pro-Q 2 doesn’t test the pointer before dereferencing it, but reading the VST3 docs I get the impression that NULL is not a valid return value for addParameterData().
So it seems to be å bug in the Juce vst3 wrapper, combined with some optimistic coding from fab filter?
Gahhhh! The VST3 docs aren't very clear about anything; they're some of the worst I've ever seen for this reason... And not checking for nullptrs?! No wonder I'm losing my hair...
Potential fix, tested with success here on my end:
I'm on call right now, so have a bit of time on my hands while waiting. I managed to test a slew of other plugins against the new code, and haven't found any issues. But, of the many plugins I have installed, very few make use of the ParameterChangeList in the JUCE Plugin Host.
Jules or Dave; I think the only thing left to do to sanity-check this code is to load up a VST3 in Tracktion, and get some automation going with it.
Dave pointed out that the implementation you posted isn't thread-safe, and these change events will be coming both from the audio thread and the GUI thread. So once I get some time to add some kind of locking, I'll post the results..
It's impossible for us to know what FabFilter are doing internally, so only they can answer the question of whether this is something we'd need to fix.