Ive just moved one of my externals which is similar (eigenharp interface, so also sends a lot of data, from a usb source), it had issues with Max 7, the main one was the sequencer being a lot more responsive. i.e. i was getting 10x more clock ticks that i used to get (i used clock_fdelay(,0.0) ) , not an issue with Max7 (in fact an improvement!) but did mean I create a lot more cpu load than it did in Max6, which had side effects, so I needed to adjust my code. (I think the mutex etc that i use, continued to work as before, as far as i can tell)

I am however, getting more memory exception, its really hard to see why, as its always crashing inside Max/Juce randomly, and at different times in my externals life cycle… often just looks like the (too common) normal max crashes (by normal, i mean the same, as when I don't use 3rd party external, just cycling objects). perhaps its related to some change in Max7/externals perhaps not, perhaps unrelated Max7.0.0 teething issues.

on a positive note, so much more comfortable dev environment, now we can launch the Max7 (full) from within Xcode, rather than the limited runtime, makes dev cycle much faster (for me)… even the recovery can help.

I did follow up on the dev side - thanks!

Regarding C++, I can say in my role as "C++ expert" (well over two decades, off my lawn you rotten kids!) that Max can't possibly tell whether it's being called from C or C++ and as long as you the programmer are careful to not use C++'s concurrency mechanisms (threads and mutexes) and only to pass known C data structures to the Max, there will not be an issue. I've done this for years, and so far not run into any problems that way.