[dterry]

I don't think it's a graphics card issue or cpu as I've tested this with nothing else running, and low/no cpu load in PT - just a large number of midi tracks, and the problem scales depending on how many tracks are in the session.

(in my normal setup, I have VEPro running outside of PT on the host system, as well as slave systems feeding back into PT (hardwired). Midi Over Lan to the slaves. It works very well - incredibly happy with the setup other than these two (rather major) issues.)

I've tested these issues without VEPro running and without external slave inputs - just a blank PT session with 200+ midi tracks just to rule out other factors. Cpu usage is almost non-existent in the test project since they are just blank midi tracks, one clip to test opening in the notation editor. Same result - and it has been this way since 8, except in 8/9 I could just deselect all of the tracks in the track list and the notation display would display correctly. It's defaulting to selecting every single track/clip when opening from the track window. When opening from within the key editor, it only uses that midi clip, but takes forever (PT9), but in 10, it locks up PT.

Fyi - for the notation display as in your Mozart session, you do have to setup the cleff/staff view for each track - that's not included in a midi file, and if you created the session, midi track notation display settings always default to treble clef until you setup the the display parameters for it.

That part works fine here, it's just how PT handles a large number of midi tracks - it's trying to scan everything (and very inefficiently apparently) - it shouldn't. This never happened when I used Nuendo, or Logic back in the day.