Thanks for your thoughts, guys.
It’s not a MIDI Channel problem – I can make the panel work in standalone, and it also works if I use a MIDI port not referenced in MIDI Device Manager.
It’s not a Windows port sharing problem. I definitely CAN share ports inside Cubase. I am only using one ‘app’ – Cubase. It’s just that Ctrlr (as a plug-in – I’m not running it separately) cannot access any port that is referenced in Cubase’s MIDI Device Manager. If I remove the reference then Ctrlr accesses the port just fine. Removing the port in Cubase isn’t an option anyway – I then wouldn’t be able to play the instrument in Cubase.
If I use a port that *isn’t* defined in MIDI Device Manager, then Ctrlr works perfectly – and that port can be in use multiple times. So it’s definitely not a Windows sharing thing – just a specific conflict between MIDI Device Manager and Ctrlr.
I could remove the MIDI Device Manager reference, but then I lose my ability to access hardware instruments by name. I’m not very happy with this prospect. That’s why I would prefer to use the ‘output to host’ option from Ctrlr – which doesn’t work at all. But I’m narrowing it down…
When using the Ctrlr ‘output to host’ option – it looks like Cubase is intercepting the data generated by the Ctrlr panel. For one example, when I move the VCF Frequency control in the MKS-80 Ctrlr panel, one of the Quick Control knobs in the Cubase Instrument window also moves. This suggests that Ctrlr is generating the data, and Cubase is aware of it, but that data is not being allowed to escape from the instrument.
An Eagle for an Emperor, A Kestrel for a Knave.