Due to fighting with the Midisport 8x8 I have been removing and adding virtual ports as well as uninstalling and reinstalling the Midisport drivers. On the Bome side I now have some interesting.anomalies. Under Sound, video and game controllers everything looks normal. I did remove the midisport and installed a new Windows 10 compliant 16x16 unit.
However in Software services there is an issue as each Bome virtual device shows up twice.
What makes it more interesting is that the properties do not match the Service Name
Note FB01s shows as location Proteus 2K
In the registry FB01s show up twice in both capture and renderer with different GUIDs for each of the tow instances. This is also true in the Media catalog.
What do I need to do to houseclean the registry since deleting virtual devices does not seem
to clean everything up?
Same goes for getting rid of 130+ entries in Device Class that the Midisport uninstaller did not remove since these are the new class entries that Win10 generates all by itself?
I would not recommend messing with the Windows Registry. For Bome Products that best way to resolve this type of issue is to uninstall and re-install the software.
You would have to talk to MidiSport about how to resolve there drivers.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi @jmcdouga ,
as Steve said, it is very risky to edit the registry, especially wrt drivers. My main question is: do you have actual problems with the virtual ports? If not, I wouldn’t try to fix it by editing the registry…
Some infos:
All virtual Bome ports appear twice under Software Devices. It seems that INPUT and OUTPUT are listed separately here. This is nothing we, as the driver manufacturer, have control over.
We sometimes hear that our driver “forgets” to remove some registry entries (or files) when the driver gets uninstalled. This is a common misconception. Driver installation is entirely handled by Windows itself. Our driver installer only points Windows to our .inf file and then Windows installs the driver and creates all those registry entries for its own housekeeping. When uninstalling, Windows keeps some information in the registry, and in the filesystem, to facilitate re-installation (which takes much less time then). This is standard Windows behavior and there is no way I know of to safely get rid of this driver cache. So it is rather dangerous to manually remove those entries from the registry. It will lead to an inconsistent Windows driver cache.
It is also not necessary to try to clean the registry in this regard. The risk is much higher that a driver will never work anymore than the perceived problem of having a few extra kilobytes stored in the registry. AFAIK, the registry will not get slower when it grows.
The Bome virtual MIDI driver consists of 3 components:
bomebus.sys – the bus driver responsible for adding/removing ports
bomemidi.sys – the port driver
bomemidi_coinst.dll – a co-installer helper to fix the port names, which sometimes get mangled by Windows
Each of these components exists in a 32-bit and 64-bit version.
(I’ve edited Steves reply which had slightly misleading info in this regard)
I don’t know why the location is off on your computer. On my test system, I have more than 200 virtual Bome MIDI ports, and their location is aligned with their name. However, this location text is not a functional thing, it’s just a text to display to the user. Our virtual driver tries to reuse slots when removing a virtual port and then adding another one – but again, the location text is not actively managed by us, but by Windows. In any case, it’s possible that Windows somehow gets out of sync with the location text, but the respective MIDI ports still work 100%.
If you run into problems with the Bome MIDI virtual ports, the installer provides a trouble-shooting option:
So I played safe and nuked both mini NUCs I am playing with and reset Windows. Then I plugged in the class compliant 16x16 midi unit. No drivers required. I get a nice clean set of definitions in Device Manager.
All 32 ports on the 16x16 show properly
Verified by running Soundigy Midi Mapper - Input and Output ports show as expected
Did not install Midisport as the new 16x16 replaces it.
Now the key issue.
When I ran the Bome Network installation, in the Sound , video and game controllers section, the Midi 16x 16 entry disappears and in the Software Devices all the Midi 16x 16 entries disappear as well. Windows 10 supports at least 64 ports so there shouldn’t be an issue with having 32 physical ports and up to 32 virtual ports. For any given 16x16, I will only have 10-12 units attached to each one. I have two mini NUK / 16x16 setups and expect to end up with 5 or 6 of these with the Sequencer PC (Sonar) and the Patch Manager(MidiQuest) PC in this setup.
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.
