Midisport 2x2 Driver Windows 10

[Latanya Hariri]

Dueto 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.

Capture1355511 5.47 KB

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.

mediaCat1807116 5.67 KB

MediaCat2890147 8.53 KB

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?

Capture17557574 8.2 KB

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.

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.

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.

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.

With the emergence of USB as a standard, MIDIMAN, later named M-Audio, was an early innovative manufacturer who created USB interfaces that would convert the digital MIDI protocol to/from USB. When I joined tomandandy Music Inc. in 1999, to work on an early AI based automated composition system, external MIDI devices were still needed for the synthesis of production quality sounds. The project was developed on NeXTStep/OpenStep, for which I had written a Roland MPU-401 (one of the first PC MIDI interfaces) driver as a contractor for them, before moving to the U.S. An early task was converting the project from OpenStep to run on beta versions of MacOS 10.0.0.

Since musicians tend not to be flush with cash to throw out perfectly good hardware because of a lack of software support, I have modified and updated my original code that was donated to M-Audio, to now compile as 64 bit versions on these latest MacOS versions, so MIDISPORT owners can continue to support and operate their hardware on the newer versions of MacOS. The code has been released as open source under the liberal MIT License. I hope this small contribution can help people continue to make music with old synths and share it with the world.

If you feel so inclined, the easiest option is to send donations via my PayPal address leigh AT leighsmith DOT com. But the fact that people are able to benefit from the driver, and continue to use the hardware to make music is reward enough for me.

When I plug in the device (midisport 11) I can see that the MIDISPORTfirmwaredownloader does appear in the activity monitor app (briefly). The USB light on the device does pulse slowly and continuously. Unfortunately it still does not appear in the audio MIDI Setup app.

I just want to say a big thank you! After I have upgraded my Mac to OS 13.2 Ventura, the old 3.5.3 driver that was running under Mojave did not work anymore. I have found your driver on github and I have installed it. Now my good old Midisport 44 works again! I am very grateful!

Which version of the driver did you use?

I am running Ventura on a new Mac Mini and cannot get it to work.Any additional setting to use, or enebla/disable some security features? (I am using a Midisport 88)

Hi man, I just came to say a big thank you, I just update my imac to Monterey from Big Sur and the previous midisport driver crashed all my system, I was looking for 2 days what was happening and at the end when I found it I was trying to find a driver to work and I came to your driver that was a huge relief, you saved me from a format that I was ready to do. Thanks again!

Please find v1.3.1 files, along with earlier versions, available for download at SourceForge. Please read the README for the installation process. For the MIDISPORT 22, you will not need to download the optional old M-Audio driver.

The latest version of the open source MIDISPORT driver is v1.3.1, which addresses a number of problems running on recent versions of MacOS. I would recommend downloading v1.3.1 and installing that as the first thing to try?

Usually you should be able to open the System Settings app, and under Privacy & Security you will see a notification about the MIDISPORTDriver installation, and you should be able accept the exception to get it to Open Anyway. I will look into the work and money required to properly sign the .pkg file.

In principle, if we can find a copy of the software and run it on a 10.6.8 system, we can probably use a USB packet sniffer software to determine what messages are being sent to the 88 in order to write an open-source tool to recreate those messages. The only thing I can suggest is for readers to investigate the original CD-ROMs that were shipped with the hardware and look for the software there. In principle, if there is a Windows equivalent of the remote manager software, that could also be inspected to identify the packets, using a Windows machine, perhaps more easily than using a Mac able to run MacOS 10.6.8. But as you suggest, the first task is finding the software as shipped by Midiman/M-Audio.

Hi Leigh.

Months ago I was testing my MidiSport 11 on my MACPro 3.1 with Monterey 12.7.2 and your driver 1.3.1 and it worked perfectly. After updating to 12.7.4 it no longer recognizes it, the LED does not turn on.

I have installed the driver on a Macmini with Monterey 12.7.2 and it works.

I have checked the files that have been installed on both computers and they are the same.

Are these all the files?

Hi,

I don't know, if I understand you correctly, but if you want to use the keyboard just as a MIDI-Controller, all drivers are already contained in your Linux distribution ("alsa-drivers"). No vendor specific drivers are needed. USB-to-MIDI is class compliant normally.

I'm using a USB-to-Midi cable, as I did before on this machine when I was running Windows XP. The reason I assume I need a driver is that there is no audio or _visual_ response after I hook everything up and load PianoTeq -- by which I mean the graphic in the PianoTeq window that would show the keys on my YPG-235 are being depressed. In other words, it seems as if PianoTeq is not recognizing any connection to the keyboard.

I saw a picture of the Yamaha YPG-235 and it just seems to have an USB-output. It should be possible to connect it directly with an USB-Port of your PC. Sometimes it works better with an USB 3.0 Port, which has a higher current than 1.1/2.0. Wherefore did you use a "USB-to-Midi"-converter?

tango studio, ubuntu studio, kx studio... are just distributions like your ubuntu. An environment around the Linux-kernel. They are just more specialized for audio-purposes an have more audio-relevant Packages preinstalled.

3a8082e126