Virtual Midi Port Problems
Hi,
I`m having problems with a virtual midi port and cannot find the way to solve it. Maybe someone can help..
The Max Standalone recognize the virtual midi port correctly the first time I open the app that creates it, but if closing the app and reopening it again, the midi port is labelled as an instance "OriginalName #2" so it`s not working anymore. If I close and open the app again it goes to "OriginalName #3" and so on.
It looks like in someway the port is not really closed after closing the application that created it, even not being available within midiin or midiout objects, and dissapearing from the ports list at Max Midi Setup window after closing the app that created it. It looks that the operating system automatically assign a new name to avoid conflicts, as the port has not been completely freed after closing the application that created it. This results in names like "OriginalName #2".
Does anyone had any similar issue? Any ideas on how to solve it?
Thanks in advance.
Are you using pre max 8.5 or max 8.6 version ?
max 8.3.3 and prior do what you describe,
but 8.6.2 on my system does not.
I was on max 8.5.6 but I downloaded 8.6.2 and I`m having the same issue. If I close the app that created the virtual midi port and re-open it again I get "OriginalName #2" again.
which app did create virtual port ?
P.S.
I just tested also
#SM createoutport messages
have one max app open, launch the other & create virtual port, quit it,
reopen it & create again,
the first one still receives midi correctly from virtual port
no matter if initial from Max or one created by message to #SM
It`s a prototype app, not released commercially. When checking on a DAW, let`s say Cubase, Logic or any other it does not happens, the port is showing the right name after reopening the app, but with Max there is a problem and it does create instances #2 #3, ....
so it looks an an issue associated to Max MSP.
I thought it is also Max created app
On Mac I do not use that from / to ports. never.
Rather steady IAC busses which allways work correctly.
The app creating the virtual midi port is not Max app. I don`t know what else to try to avoid this issue and make sure that the port in freed 100% when the app that created it has been closed, so when opening the app again it creates the same port name, not an instance #2...
Is there any command to make sure that the virtual port is 100% closed and freed?
When I run my Standalone, I use Max messages to clear the MIDI Setup completely before allocating new definitions according to my desired setup:
I don't know if you could use something similar to make sure that the port in question is released from Max before you restart your app?
The other possibility that comes to mind is to use a loopback application that can handle multiple simultaneous client connections to a v-port without hogging it and use that to link your app to Max. loopMIDI by Tobias Erichsen works very well for me on Windows but I'm not sure what's available for MacOS:
Hi Andy, thanks for the support.
The loopback app is not an option by now, I would need to use Max messages probably.
Does your posted messages clear the whole Midi setup? Let`s say that the virtual midi port is called "Arkana", is there a way to tell the system to clear this "Arkana" virtual port so when loading it again it does not show as an instance "Arkana #2".
When I close the app that creates it, the midi virtual port disapears from midiin available devices and also from the Midi Setup window, so it should be 100% freed.
When testing the same process using Nuendo, it works properly, it does not create instances each time i close and open the app that creates the virtual midi port. So the issue is related to Max only...
If you prefer not to use IAC buss, but only port from that app I don’t see any way to prevent
buildup of # versions of recreated ports.
Max keeps initial reserved port names in
memory and also writes all added ports in midi setup file.
What you could do is enable autoreport of changed midi ports and run results through
regexp to match initial port name
Ok I see, it`s not easy to fix in Max.
How can I achieve that? "enable autoreport of changed midi ports and run results through
regexp to match initial port name"
I will post a patch when I get home in 1 hour time
Maybe you can get it yourself
check attributes to midiinfo object for the first part.
Then you run output through route append
into regexp and so on …
Sure I will check it now
this should work for virtual port named Arkana.
if it gets recreated under "Arcana #1" "Arcana #2" etc,
max should adjust to new port names
Does your posted messages clear the whole Midi setup? Let`s say that the virtual midi port is called "Arkana", is there a way to tell the system to clear this "Arkana" virtual port so when loading it again it does not show as an instance "Arkana #2".
Yes. The example that I posted clears the whole MIDI Setup. [midiinfo] lists all the MIDI ports that Max knows about and as each is pushed into the $1 placeholder in the Max message, the port is deactivated and any mapping abbreviation is removed.
In your case, you could just use the following Max message to disable your chosen port:
However, as SourceAudio has mentioned, Max has a habit of indefinitely accumulating new symbols during any running instance and there is no way that I know to of to remove them. So even using this method might not work if Max refuses to link to a port with the same name as it already has in its dictionary!
Thanks guys I will test both solutions and will get back to you ;)
Any of both solutions has worked and the issue still there, creating Virtual Midi Port instances after reopening the app that created the port. Any ideas?
can you post some screenshots of patch I posted showing exactly
what gets listed as midi ports,
and what actually does not work ?
receiving/sending midi ?