Disabling Max Virtual MIDI Permanently?
Hi!
I'm familiar with the message box commands:
;#SM deleteinport
;#SM deleteoutport
Which work fine, but only remove the ports for that Max session. If I restart Max 5.1.1, the ports re-enable themselves. Is there a way to prevent Max from creating these ports every time?
Thanks!
No. You can loadbang those messages, but even so, the ports will first be created then deleted at every startup.
Thanks John. That's not what I wanted to hear, but that's life I guess. It unfortunately creates issues with coremidi re-enumerating ports, which causes loss of communications with control surfaces and messes with controller assignments in Logic Pro. I think I'll write to Cycling74 and request a disable feature for the next version.
Thanks again.
I'm very very familiar with Logic's issues in this area. I advise my users to start my app before Logic.
One thing that may help is to get the port id of the virtual ports you create, and attempt to create those ports with the same name and id at each restart, not just the same name.
In my experience the virtual ports sometimes also mess up existing assignments to IAC in Ableton Live.
So a disable feature would indeed be very useful.
Some years ago I've already asked for this but was told that it can't be implemented easily.
Cheers guys. I've sent a "pleading" email to Cycling74. Hopefully we can get this resolved the right way. Fingers crossed!
cycling isnt exactly the most responsible adress for coremidi issues^^
But no doubt cycling is responsible for creating virtual ports by default..
I'm largely with Roman on this - Logic and other apps are supposed to be able to handle virtual ports coming and going at any time. But it would still be nice to avoid creating more than we need at startup.
Since we have IAC built into OS X, creating virtual ports from apps generally doesn't make much sense.
It's the other way around.
IAC is a hangover from OS 9 where it was the only way to do inter-app MIDI. IAC timing can be pretty flaky, and it's a weird system where each bus is 2-way - this can make out-of-control feedback loops very easy to accidentally set up. Doug Wyatt has stated that providing it in OS X was simply a way to encourage many smaller MIDI app developers to support OS X, not a long term solution.
CoreMIDI virtual ports are better behaved (when implemented correctly) and more flexible. You can't create an IAC bus programmatically for example (even in low-level C). Apple recommend that apps should use virtual ports rather than IAC.
Thanks John for the info. I understand that the bus concept of IAC is problematic.
But I wonder who's the culprit for messing up the programmatically created ports?
a) app that creates the ports
b) app that uses the ports
c) coreMIDI by design
Apps are supposed to be able to handle the ports created by other apps or plugins appearing/disappearing, remember what was connected where, handle the situation somehow (most likely by doing absolutely nothing), and restore the right connections when appropriate. Logic has always had way more trouble doing this than most apps in my experience, tries to be too smart and bugs the user with error messages, then screws up anyway - I don't think C74's implementation is at fault.
"I don't think C74's implementation is at fault."
I don't either. In my opinion the blame is squarely with coremidi and the whole driver model. There should be a way to manually make ports persistent, regardless of whether the device is connected or the app creating the virtual device is running or not. Kind of a device and port mapping preset system. John, is my memory correct that we had that ability with OMS, sort of?
I'm not going to hold my breath waiting for Apple to fix it. I'm sure it wouldn't be a big deal for Cycling74 to make an option to disable this, even if it was just an installation option rather than a preference. So I'm hoping.....
OMS invented IAC busses, which are persistent, but have other issues as noted.
The big deal for an app is that you have to tell your users to go create an appropriate number of IAC busses and either name them according to some naming scheme (and your app then connects automatically), or manually select the appropriate IAC bus numbers in your app. Virtual ports are much simpler for the user.
The problem is not the coremidi model, or a driver (there isn't one, yay), it's app developers not correctly handling the fact that virtual ports are by definition not persistent. It's perfectly possible to deal with that, but apps like Logic appear to have a legacy mindset about midi i/o being hardware, and just screw it up. I don't think that part of Logic's code gets much developer attention. Note Logic can exhibit similar problems with usb midi devices disconnecting/connecting.
Even if you can prevent the default ports from being created, starting your app after Logic will still cause issues because you're adding virtual ports to the system and Logic may do its rearrange/reorder thing anyway.
Logic also won't reliably remember virtual ports by name between restarts of your app, you need the same name and the same coremidi id, so you'll have to create the port with the same id as mentioned.
I've found the best solution is just to tell my users to start my app before Logic. That's simple. After a few experiences where they don't, they get the idea.
"I've found the best solution is just to tell my users to start my app before Logic."
This simple scheme doesn't work with MaxForLive: Max is automatically started *after* Live and creates the virtual ports. As discussed on the Ableton forum, this sometimes confuses the existing port assignments of Live. The only solution found so far is to bypass Live's midi port management via system level Max externals.
I agree with John that dynamic virtual ports are handy for the user and appropriate to modern software.
But apparently the concept is not implemented correctly in major DAWs like Logic and Live.
For this reason a disable feature in Max would be useful in practice.
We are looking at ways to alleviate the hassle that this creates for some applications. I can't guarantee that something will be implemented, or if implemented, when it would show up, but just wanted to let you know it is on our radar.
Thanks!
So it seems the question is:
How do I get the port id of a virtual MIDI port created in Max, and how do I re-create that virtual MIDI port id whenever an app is loaded?
Does anyone have this?
Max should fix problem about the virtual Endpoint that created from another clients or another applications
because Max never remove an invalid endpoints until I restart Max Application.
You can create new ports by sending messages to the Max application:
;#SM createoutport
You can query the port list with the midiinfo object.
-Ben
Thanks Ben.
This message to Max was addressed earlier in the thread. The "port id" I am asking about is the one that @johnpitcairn mentions above: "the port id of the virtual ports you create, and attempt to create those ports with the same name and id at each restart, not just the same name."
Is that the same one discussed here:http://stackoverflow.com/questions/7642136/how-do-you-retain-uniqueness-of-virtual-midi-source-from-midisourcecreate?
And, if so, does Max have a way of exposing this data and making it persistent as part of the virtual port creation process?