Sorry for all these problems… I wish I knew what is going on there! Our virtual MIDI port driver is extremely stable and well tested for many years. We have never heard of such a problem or even any kind of incompatibility with the Microsoft class driver. In-house we’re regularly using and testing dozens of MIDI devices and multi-DIN interfaces in conjunction with our virtual MIDI ports. Many people actually use our virtual driver to work around other buggy MIDI drivers… So for now, I still think it’s more likely that another driver or component causes the incompatibility.
A few questions and suggestions:
Have you tried unplugging + replugging the 16x16 device?
where is the 16x16 device in the Device Manager after doing so? It must be somewhere!
You can also try this:
in Device Manager, the root element of the device tree is your computer name
right-click the computer name and chose “scan for hardware changes”
if the 16x16 is still not showing, you might try the option “show hidden devices” in the View menu.
does uninstalling the Bome MIDI driver (using our uninstaller from Settings → Programs and Features) fix the 16x16 ports? Exit Bome Network prior to uninstalling the driver.
Which brand and model is your 16x16 interface?
What is this “ESAuDriver Device”? Maybe that one is incompatible (somehow) with standard MIDI drivers?
Same for the other devices appearing in the “Software Devices” list…
The 16x16 is made by Midiplus. www.midiplus.com.tw
They were M-Audios development partner up until Avid bought M-Audio and worked with M-Audio for years
Thank you for the detailed screenshots. Bome Network normally detects and displays all MIDI devices in the system.
are the 16x16 MIDI ports showing in other MIDI software?
despite its auto-detection of MIDI ports, have you restarted Bome Network? (you must use the tray icon’s right-click menu for that)
Maybe, restarting your computer will help?
When googling this issue, I have not been able to find anything like this. Some people are reporting specific problems with this 16x16 interface (or the same under different brand “Miditech Midiface 16x16”), but nothing similar to your issue(s).
On a related note, I found this:
We’re aware of this renaming issue in Windows and our products work around it internally. And we took a number of extra steps to prevent our virtual MIDI driver to be affected. Now of course, the described issue is not related to the one you’re having, but it’s worth a quick try to unplug the 16x16, remove all traces of it within USBDeView, and then plug in the 16x16 again…
Think I found the glitch. It’s seems to be a timing issue. On one side the system is loading the midi class driver and enabling the 16x16. On the other side it is loading Bome Network. It seems like Bome network reads the midi ports during its load and since the ports are not yet enabled it doesn’t see them and load to its port list. If I disable the auto start in Bome Network and then load it after everything is up, it will show the midi 16x16 ports in the router
Interesting. I think Bome Network, normally detects new MIDI ports when they become available. I’m not sure with the message to signal available ports comes from Windows or from the MIDI port driver. I’ve seen this issue on many different software where they do not detect (some) MIDI ports when they come on line.
Started Bome Network Pro with MidHub not plugged it. No MidHub ports (there are four of them show up).
Plugged in MidiHub and now the ports show up without needing to restart Bome Network Pro.
So this is a physical controller that exposes 4 ports. If the 16x16 presents it’s ports as virtual ports, then this might be an issue. I think I’ve seen this issue when adding LoopMIDi virtual ports.
Edit : LoopMIDI detected OK too. What version of Bome Network are you running? Please make sure you are running 1.4.
This is really interesting. All our software works like this:
on ‘new device notification’, it reloads the list of MIDI devices
10 seconds after that notification, it checks again to see if the list of MIDI devices has changed.
Now it seems that at start-up, the 16x16 ports are not yet fully initialized, and there is no ‘new device notification’ when initialization is done. So, I guess that Bome Network should check for new MIDI devices 30 seconds after start-up, and maybe also after 60 seconds. We’ll add that to the next version.
PS: glad you have found a way to get started at all!
In Device Manager everything shows correctly so the conundrum is why they disappear after a period of time from Bome, and when they are missing in Bome, they also do not show up in other midi tools. Seeing the same thing on both machines with 16x16s attached.
It appears that the MIDI 16x16 is not behaving correctly or maybe periodically dropping off line.
What you see can also happen (red) when some other application is using that MIDI port so it cannot be used within the Bome Network MIDI router. On Windows only one application can use a given MIDI port at at time. See my posting here on how you can share MIDI ports using Bome Network Pro.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
So I ran a test today. I set up a laptop this AM with Bome Network installed and plugged the 16x16 into it and configured a route to it on the laptop. Even with it going into hibernation off and on during the day as I would wake it to check status, the route never dropped so I can eliminate the 16x16 as the problem. Next step, troubleshoot the miniPC. This is the first time I have had to deal with EUFI Bios. In going through the system event log, I am seeing a bunch of warnings about power draw on the USB port the 16x16 is connected to. These miniPCs do not have much of a power supply. I have a theory that the Bios is shutting down the port or bouncing the data connection after the power draw persists for a period of time. Have ordered a power splitter cable to see if by drawing power from 2 ports this impacts what is happening. Cable should be here Monday. Will keep posting as I do the root cause analysis.
How about a powered USB hub? Most of them can handle much more power. I know this might not be what you want on a MIDI PC. I have a powered 16 port USB hub and sometimes I have something attached to all 16 ports and never have power draw problems.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
In the Midi 16x16 manual they specifically say not to use a hub. These micro PCs do not have much of a power supply and I can see a stream of warning messages in the System log about power draw on the USB port the 16x16 is attached to. These miniPCs also have issues with USB power external Hard Drives.
Well if your 16x16 is drawing more than 500ma of power then that could be the problem. I your micro PC cannot provide up to 500ma of power, that could also be a problem. If you use a splitter, I’m hoping it uses only 1 USB for data and the other to provide power only.
So I implemented the splitter cable USB 3.0 to USB 3.0 power and data and USB 2.0 power only. No more power warning messages in logs but still have the problem with the ports disappearing. Continuing to track this down. Installed a Lenovo M93 mini (i5, 8GB). On this machine everything works fine.
Success !! I had to disable power management on both USB hubs, the USB root Hub and the eXtensible USB device. After that everything worked as it should. The USB power splitter cable solved the power warnings in the system log. Now have three racks up and running.
wow, that makes me happy! I can only imagine how much trial&error you’ve had to go through to finally identify this solution.
And thank you very much for posting here. I assume you’ve disabled USB hub power management in the respective Device Manager device property pages? Or is there a tool for that?
Yes they are two separate issues. With the one miniNUC, it was logging power warnings but the other one was not. (two different brands with different power supply ratings). The power splitter cable resolved the warnings on the one miniNUC.
The main issue seems to have been functionality in the EUFI BIOS. The renewed Lenovo Mini had no issues from the start, but the two cheaper miniNUCs did. The Lenovo did not have the same type of BIOS (older). I believe the USB power management functionality is a feature in the newer versions of EUFI Bios. I had not seen this before.
With this issue resolved it opens up opportunities not only to do what I am doing, using cheap <$140 miniNUCs to interface in 8x8 and 16x16 Midi port devices, but also the ability to use these to run VST racks containing multiple VST synths without loading them into a DAW saving resources on the DAW.
