Setup Pianoteq for 7.1.4 Multichannel outputs

I haven't properly looked into the 3D-Audio support of Pianoteq yet, but have you looked at the Return-Channel for the Multiout-Instrument in the Track-Inspector section of Cubase? :-)
If you activate additional channels there, you should be able to assign them.

So, I've figured out how to assign the microphones using the instrument busses provided by the Pianoteq 9 plugin in both my DAWs. The Pianoteq manual is very vague and was not helpful (and by the way if there is a downloadable PDF manual, someone please point me to it since I can't find it and I don't want to depend on an Internet connection for that).

From the manual:

12.2. Mixer
The mixer allows you to mix up to 8 microphones into up to 8 Outputs (also named Bus). For each microphone and each active Output, you can Mute or Solo and you can adjust the Volume, the Pan, left Land right R Delay and polarity (clicking on Lor R). Your audio configuration may impact the Output behavior and you can add or remove Output clicking on the Mixed Output title.

In both my DAWs, 7 additional 2 channel busses (separate from the stereo mixed output) appear and can be assigned to tracks for monitoring/recording, BUT no actual audio is routed to them until you "add new output" in the Pianoteq plugin by clicking on "Mixed Output" in the plugin mixer.

Then you will see two tabs to the left of "Mixed Output". Each tab number corresponds to the associated stereo bus (although both my DAWs show the 7 added busses each as 2 mono pairs (for example bus 2 is shown as 2-2 instead of 2L-2R). Tab #1 corresponds to the main stereo out, #2 corresponds to bus 2, and so forth. Each tab switches the mixer to show the faders for the corresponding bus (like pages), and up to eight microphones can be assigned to the corresponding bus for that page.

So in effect you can send up to 8 different stereo mixes to your DAW. Then you have to figure out how to properly assign them in your DAW to create a 7.1.4 channel configuration that sounds appropriate for your production (in my case, I want an accurate live performance effect).

Speaking of effects, I did not find a way to route reverb or other Pianoteq effects to a separate bus, and the included effects seem to be stereo-only. I'm thinking that if you don't want the image smeared in your immersive mix, you will probably need to turn off the Pianoteq reverb and use a good 7.1.4 reverb fed by a 7.1.4 bus in your DAW.

Yes, it would have been far easier for PT 9 to support 7.1.4 directly. I had previously requested 7.1.4 plugin support. Can we look forward to that in PT 10, please?

Thanks you so much Robin. I will be working on an Atmos music album slated for release next year, and can send you a pre-production example when we get to that phase of the project. Before that I need to spend time experimenting with PT 9 microphones and determine whether I will need to upgrade to PT 9 Standard if I can't get the right sound with the fixed mic positions of the Stage version.

This is a great time to be using Pianoteq... it just keeps getting better and better!

Not sure if Pro has different (more refined) microphone emulation features than Standard.  It's been a while since looked at that specifically.

I haven't upgraded to 9 yet (will do in the next couple of weeks--just been too busy, sadly).  So I'm still stuck with 5 microphones in v8.  However, if you right-click or long-hold the middle of the microphone icon, you should get an input dialog that allows you to manually specify axial placement in 3D space (in meters I think) and then a horizontal and vertical angle in degrees (again I think that's in Standard but I'm sure it's in Pro).  All of these are controllable (at least in Pro) by MIDI, so you could do some wild and crazy things that are functionally impossible in normal recording situation.  (Why you would need MIDI control of a ILM-style "starship filming rig" is at the very least a rare use case, but PTQ has you covered if you need motion control of microphones that matches motion control of a video rig.)

Not sure what to say there as I don't use Studio One.  It's possible that's PTQ's fault generally, PTQ 9's fault specifically, or just Studio One's fault.  If it's either of the former, then giving diagnostic logs to the PTQ developers through an email like their support address is likely the best option.  Making multiple instances that don't require you to pair/link as frequently might be good.  Again, knowing nothing about how Studio One routes and sums connections, all I can do is speculate.

Sounds plausible--assuming the crash problem goes away.  Two instances of the VST should work correctly in parallel the way you plan, at least as far as microphones are concerned.  The only ways I would envision that getting into trouble is either if Studio One isn't hyper-precise with it's CPU/global clocking (though you'd have something like that in the real world with any analog rig where reality causes a jitter-like equivalent that we usually call "warmth" and say it adds character) or if you route different notes/MIDI instructions to different instances as the resonance model won't know about what the instance is doing.  As long as you're passing the same MIDI data to both instances, the model/engine should just treat the second instance as an extension of the first (especially if you're not summing the inputs in a weird way that causes phasing down the road but since you're entering it into a spatial reverb engine/emulator, your end use case isn't mono broadcast that somehow retains the character of the Atmos mix--as that's just impractical and impossible).

Agreed.  I like all of these ideas, and hypercardioid would also be welcome as room mic option.  I'm looking forward to any future additions to the microphone system.

Nice!  Glad that's working!

In theory, you could fully compartmentalize and have an individual instance for each microphone.  Also, technically speaking, you might not need to pair microphones at all--as long as they're routing to the correct output, as the pairing function (if my memory serves) is more about organization, user interface accessibility, and convenience than actually changing how the microphones behave from an i/o standpoint.  Another possibility is that the crashes have more to do with Studio One's internal input/output routing, in which case, limiting yourself to 4 microphones per instance might just be what you're needing.  So, with enough CPU, four instances with four microphones each might avoid the crashing problem while giving you the 16 microphones mentioned earlier (just a theory but promising).

Great!  Keep us posted!  I'm really curious to see if we can make this work.