Rather confusing isn’t it!
Hard to diagnose when daws are all handling it differently, some of them using hacks to play well with vst2 instead of moving to full and complete vst3 compliance.
How Studio One handles CC ...
I noticed with studio one, for example, that if I set up a chain of midi plugins in studio one that generate midi cc’s with vst2 and feed that into a vst3 plugin, the vst3 doesn’t see the generated cc’s. On the other hand if I add midi cc events to a controller lane in studio one, then those do show up as parameters to the vst3 plugin.
My feeling is that studio one is actually being very true to the vst3 approach. It’s keeping the cc controller lane data seperate from midi notes in a separate queue and then when calling back to vst3, it already has the cc’s ready to go as parameters for the vst3 plugin. But since it handles it that way it does not bother to look at the normal midi stream going through earlier vst2 plugins to see if there are cc’s there too. So the vst3 never sees them.
In truth they are handling it the way steinberg wants it to be handled, but that also means vst2 generated cc’s can’t be passed along the midi signal chain in studio one.
How Cubase handles it ...
Ironically, cubase does grab cc’s out of the midi stream before calling back into vst3’s, so at least for now they support that but according to many comments I have seen from a Arne, I suspect they might remove that at any time because it’s not officially supported by the api.
So anyway reaper could be doing who knows what to distinguish between cc’s recorded in the controller lane (or coming from your midi controller), versus midi cc generated via vst2 midi plugin (which is not a supported feature by steinberg even in vst2 by the way). In the past we got away with it because vst2 had all midi in one queue but since people are now trying to be more compliant with vst3, there is no core single midi queue anymore. So it makes sense that generated cc’s might not get through with totally undependable behavior per host and they happen to be rolling out their vst3 support.
On top of that you have juce which is trying to convert back and forth between the vst2 concept we see inside juce plugins as a single midi buffer with all midi, and the vst3 concept where there is no midi stream inside the plugin.
Juce SHOULD be converting cc Based parameters into cc events in the processblock midi buffer. And it SHOULD be doing something after the callback so that IF the host is using the LegacyCC the cc’s in the buffer will be handed to the host that way. But that assumes juce is doing its job, it assumes the host is looking for the LegacyCC conversion and it assumes there is nothing in the host or juce that would prevent that from happening in the case when there are also not at least some notes generated and added to the buffer by the plugin.
Someone needs to diagram all this out so we can all get in the same page about what is happening where.
Audiopluginhost is something by juce and we can debug the source so we should start there to see what is going whether there can be solved through improvements to juce or if simpley audiopluginhost needs to be updated, as do some of the daws