Ernest

I was ablde to get midi I/PO until I installed some virtuaol midi cables and added this. Now there is no midi output. The virtual MIDI works with other software. What do I do?

I was ablde to get midi I/PO until I installed some virtuaol midi cables and added this. Now there is no midi output.  The virtual MIDI works with other software.  What do I do? 

cant-set-midi-port-on-windows-10

Now I get it working, but Windows 10 then reports "internal error: loopback detected on MIDI port xxx." It stops working again, and it doesn't seem clear how to fix it. This appears to be a Microsoft problem.

Oh dear, this appears to be a bug in Max with virtual MIDI ports. When Max starts up, the MIDI input and output objects are all in 'all devices' mode. This causes a MIDI loopback across the virtual MIDI ports, causing a system error that disables MIDI. And so, including both MIDI input and MIDI output in a patch is impossible.

Oh dear, this appears to be a bug in Max with virtual MIDI ports.  When Max starts up, the MIDI input and output objects are all in 'all devices' mode. This causes a MIDI loopback across the virtual MIDI ports, causing a system error that disables MIDI. And so, including both MIDI input and MIDI output in a patch is impossible.


Using midiin and midiout , instead of dedicated objects like noteout etc could maybe help

Thanks for the thought. the problem is, by sending a zero at initialization, the midin object still uses the first port in the list by default, which is a virtual MIDI cable on my system, and there is no way to change that.

Thanks for the thought. the problem is, by sending a zero at initialization,  the midin object still uses the first port in the list by default, which is a virtual MIDI cable on my system, and there is no way to change that.


Now that definitely is either Max bug, or the way the Virtual Ports function.

Midi loopback would in theory only happen when midi data gets sent/received

Now that definitely is either Max bug, or the way the Virtual Ports function.
Midi loopback would in theory only happen when midi data gets sent/received
forming a loop.


Well yes, that means the midi in/out must be disabled on startup, and then only enabled if the in and out ports are not the same before playing any MIDI, I guess, but do I really have to design something like that, or am I not doing it right?

I really can't tell because I don't know what kind of Virtual Ports You are using.

Is that something new, built natively in Windows 10, or something like

And again, if You get this message about disabled ports because of loopback,

with no real loopback connection in max, it's happening somewhere else.

I am sure one could produce some kind of solution, by testing

when that happens, like starting max, creating new empty patch

adding midiout object, assigning a port to it, adding midiin port etc etc.

I would be glad to help, but have no windows machine at hand.

I really can't tell because I don't know what kind of Virtual Ports You are using.
Is that something new, built natively in Windows 10, or something like
Midi Joke or Virtual Midi driver ?
And again, if You get this message about disabled ports because of loopback,
with no real loopback connection in max, it's happening somewhere else.
I am sure one could produce some kind of solution, by testing
when that happens, like starting max, creating new empty patch
adding midiout object, assigning a port to it, adding midiin port etc etc.
So maybe You can trace it.
I would be glad to help, but have no windows machine at hand.


No you are right, max is sending midi messages at startup because the autopattr which sets the midi drivers also recalls the last set values for the synth controls, via preset and autorestore. And obviously I want the panel controls restored, and obviously they are connected to MIDI. So it does require some very special design, but it is really a max problem, because there is no way to disable the midi in/out objects. They are always connected to either all the enabled midi ports or one of them. And as virtual midi cables have the same name at both ends, there is no way to stop it from making a loopback if I share the patch with someone who likewise has virtual midi cables. And there is no other way to connect most midi devices that still work on windows, because the very much older ones that had built-in midi drivers assumed various characteristics of the windows drivers environment that has changed, since which time, no one builds midi drivers into software any more, because the music software developers don't trust Microsoft not to change it again. So one ends up always needing virtual midi drivers.

Midi yoke does not work on Windows 10 64 bit. Neither does Hubi's or virtual midi driver. Now virtual midi drivers dont install as hardware devices. They install as programs, and they don't require a system restart, and they are WHQL checked. If they try to install in the device manager device tree, they are rejected. The only ones I found so far that work are LoopBe from Nerds1 (which is shareware and only supports one cable unless you buy it, and is only 32 bit) and loopMIDI by Tobias. Tobias is actually better performance wise, except the loopback fuse is unreliable, its not clear when it resets, sometimes it takes a whole day to sort itself.

No you are right, max is sending midi messages at startup because the autopattr which sets the midi drivers also recalls the last set values for the synth controls, via preset and autorestore. And obviously I want the panel controls restored, and obviously they are connected to MIDI. So it does require some very special design, but it is really a max problem, because there is no way to disable the midi in/out objects. They are always connected to either all the enabled midi ports or one of them. And as virtual midi cables have the same name at both ends, there is no way to stop it from making a loopback if I share the patch with someone who likewise has virtual midi cables. And there is no other way to connect most midi devices that still work on windows, because the very much older ones that had built-in midi drivers assumed various characteristics of the windows drivers environment that has changed, since which time, no one builds midi drivers into software any more, because the music software developers don't trust Microsoft not to change it again. So one ends up always needing virtual midi drivers. 

Midi yoke does not work on Windows 10 64 bit. Neither does Hubi's or virtual midi driver. Now virtual midi drivers dont install as hardware devices. They install as programs, and they don't require a system restart, and they are WHQL checked. If they try to install in the device manager device tree, they are rejected. The only ones I found so far that work are LoopBe from Nerds1 (which is shareware and only supports one cable unless you buy it, and is only 32 bit) and loopMIDI by Tobias. Tobias is actually better performance wise, except the loopback fuse is unreliable, its not clear when it resets, sometimes it takes a whole day to sort itself.


So this seems bulletproof. It's a little more complicated than I hoped, but I don't think it can be any simpler.

Would it be more handy to set midi enable globaly

and send that to all midi in and out objects, instead of using gates ?

I added this change to Your patch, makes me wonder if sending enable 0

message at loadbang solves the problem as good as the gate solution.

Good news that You fixed it.
I had a look in the patch.
Would it be more handy to set midi enable globaly
and send that to all midi in and out objects, instead of using gates ?
I added this change to Your patch, makes me wonder if sending enable 0
message at loadbang solves the problem as good as the gate solution.


Well that's a useful improvement, The bono is also simpler, although it does add a bit of a delay, but it helps with layout, thank you very mu ch :)

I'm thinking the preset should also store the strings and provide an alert if the ports have changed since the last time the patch was loaded;. I'll have to get back to that on a future release, because I have alot of other stuff to do for

On further reflection, there's two problems. First, the loopback only happens if the two ports are using the same channel too. Second, it only needs to disable the out or the in port. However by loading the ports with a '0' message, and with bondo and send/receive, this was much easier to do. Thanks for the thoughts ) Here's a little picture showing how to solve the problem.

Still bugged 4 years later? Having this same problem on Windows 10. my macbook has no issue doing this...

can't set midi port on windows 10