Reply 20 of 41, by Mau1wurf1977
- Rank
- l33t++
It should work, it's just that a USB cable is more flexible and can be used on many machines including notebooks.
It should work, it's just that a USB cable is more flexible and can be used on many machines including notebooks.
Yeah, but since I intend to put together an XP system for games from around 2000-2006, next to my DOS/Win98 machine; it would be a nice "dual setup". I've seen that used Live! Platinums are quite cheap, so I'll probably end up getting one of those.
thanx.
and what about the 486 Game port with a DB15-MALE<=>DB15-MALE cable. i plug the first ent to my 486, the other end to my Desktop.
its port is midi compatible. this is works?
wrote:I was researching into those Sound Blaster cards with I/O drives, like the X-Fi Platinum; instead of using a MIDI to USB cable, I was thinking of this setup: AWE64 > Gameport to DIN midi cable > I/O drive > MUNT.
Do you guys think it would work? I already have the cable, and I think I'd rather invest into the X-Fi rather than the other cable.
I did a similar setup previously. (MT-32 direct to the X-Fi Platinum Drive). The thread is here.
wrote:wrote:I was researching into those Sound Blaster cards with I/O drives, like the X-Fi Platinum; instead of using a MIDI to USB cable, I was thinking of this setup: AWE64 > Gameport to DIN midi cable > I/O drive > MUNT.
Do you guys think it would work? I already have the cable, and I think I'd rather invest into the X-Fi rather than the other cable.
I did a similar setup previously. (MT-32 direct to the X-Fi Platinum Drive). The thread is here.
Cool. And it works when the two ports bind my game? The wiring diagram would look like this:
1-1, 2-2, 3-3 (These are pins.)
This topic reminds me of a similar discussion:
Vintage PC > MIDI > Another PC with SoundFont
"486->MIDI to USB->Laptop->MUNT" Works for me, but the 486 was actually a pentium II with roland MPU-401AT. The adapter cable was 'CME' brand. The laptop an eee-PC 1000HE.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
wrote:This topic reminds me of a similar discussion:
Vintage PC > MIDI > Another PC with SoundFont"486->MIDI to USB->Laptop->MUNT" Works for me, but the 486 was actually a pentium II with roland MPU-401AT. The adapter cable was 'CME' brand. The laptop an eee-PC 1000HE.
Ok, thanks. I will create the DB15 cable.
I think you're really supposed to have optocouplers on at least one of the directions, but it should be safe. It also won't work on pre-SB16 cards because their MIDI pins use some TTL thing because they don't have a proper MIDI UART.
Also, you can buy proper gameport-to-MIDI-DIN cables, or at least you could 10-15 years ago.
Once again, I'll explain and I would like to clarify why you would need a MIDI cable. Because it was a notebook-om outside Named the country. However, now I'm home in Hungary, where there is a PC, and you have all the ketone game port, MIDI port as well. And I do not get it. And a DB15 male cable to connect your machine 2, one of the speakers (AMD Athlon 64 machines), and the other is a 486, and the play. The Athlon 64 can run the Munt and the other to the Jets.
It olddható?
Maybe the google translator translated stupid things? 😕
wrote:Once again, I'll explain and I would like to clarify why you would need a MIDI cable. Because it was a notebook-om outside Named the country. However, now I'm home in Hungary, where there is a PC, and you have all the ketone game port, MIDI port as well. And I do not get it. And a DB15 male cable to connect your machine 2, one of the speakers (AMD Athlon 64 machines), and the other is a 486, and the play. The Athlon 64 can run the Munt and the other to the Jets.
It olddható?Maybe the google translator translated stupid things? 😕
I created the cable. Here is a link w/ in outs. The pins 15, and 12 are Crosslinked. this is does not work.
Oh jeez, sorry for posting in a 3-year old thread, first post no less, but I haven't been able to get the driver sergm wrote to install.
I copied libusb0.sys to system32/drivers, libusb0.dll to system32, and libusb0_x86.dll to SysWOW64, but every time I try to install the driver, I get a "system cannot find file specified" error.
Am I doing something completely wrong, or do I have to compile something first?
Thanks in advance.
EDIT:
So, I made it install the driver properly by actually compiling the usb-midi.dll (whoops) and put the libusb files in amd64 and x86 folders. However, now it doesn't show up as a MIDI device in any of my programs! This is really odd. Uninstalling the libusb0 driver doesn't bring back the previous "functionality", either, so I think I borked the cable.
I'm tempted to just install ubuntu on an old laptop, since apparently these generic cables work well with SysEx dumps on linux systems.
You could also consider installing Ubuntu in a VirtualBox VM if it makes sense for your use case. VirtualBox is able to take direct control of USB devices for exclusive use by the guest OS, so the host doesn't need to have a driver installed for them.
wrote:However, now it doesn't show up as a MIDI device in any of my programs!
Er, I really didn't mean that shit to be used by not a programmer, sorry...
For the newly supported MIDI device to be available in the MIDI device list, it also needs to be registered in the registry. For example, how it looks on my system:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]
"midi"="wdmaud.drv"
"midi1"="mt32emu.dll"
"midi2"="myokent.dll"
"midi3"="usb-midi.dll"
"midi4"="midi_reset.dll"
Also, you have an option when installing libusb to work either as a filter or as a driver. This is important. If it is a filter, your USB device continues to work as usual. When you install a driver, the device no longer available to the standard system drivers. Removing libusb should return it back, then you should be able to setup it in the filter mode.
wrote:Er, I really didn't mean that shit to be used by not a programmer, sorry... For the newly supported MIDI device to be available […]
Er, I really didn't mean that shit to be used by not a programmer, sorry...
For the newly supported MIDI device to be available in the MIDI device list, it also needs to be registered in the registry. For example, how it looks on my system:[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]
"midi"="wdmaud.drv"
"midi1"="mt32emu.dll"
"midi2"="myokent.dll"
"midi3"="usb-midi.dll"
"midi4"="midi_reset.dll"
Also, you have an option when installing libusb to work either as a filter or as a driver. This is important. If it is a filter, your USB device continues to work as usual. When you install a driver, the device no longer available to the standard system drivers. Removing libusb should return it back, then you should be able to setup it in the filter mode.
Thanks for the reply! Ah, yeah, that makes sense. I made it work pretty flawlessly using JACK and simplesysexxer on Ubuntu, but I'll give this a whirl as it's pretty bothersome having to boot up my laptop just to do some dumping. If I can't get it to work, I'll probably just do what HunterZ recommended!
Thanks to both of you!
Well, if it works in Ubuntu, it should also work with usb-midi.dll (using the same approach). Perhaps, it's only a matter of setting the proper CLSID for a particular USB device.
Side note: Linux in a VM may have other advantages vs. the double-booting. Device support is good generally, but I found that the battery of my NB wastes much quicker in Ubuntu 🙁
Yep, it works! I removed libusb, got back the original functionality ( or lack thereof ), installed it again, put the usb-midi.dll in both sys32 and syswow64, added usb-midi.dll to midi1 in the registry, rebooted and holy moly, I'm actually sending huge sysex dumps back to my synth.
This is so awesome. A huge thank you for making this driver, and actually giving support some 3 years after making it!
For reference though, was I supposed to set up libusb as a filter, then update the driver with your .inf? Or am I completely misunderstanding the usage of libusb? It doesn't matter much now that it's working as intended, but it'd help ease my mind, heh.
Edit: completely forgot to check if MIDI IN works, but it doesn't. Does usb-midi.dll only deal with MIDI OUT?
Whether to use libusb as a filter depends on how well the device works without it 😀 If it is broken with the system class-compliant driver, it seems to be better to disable the standard support altogether.
Also note, that way the USB-MIDI will not work as a MIDI-in. If you need to load something, it may be wise to keep the both. Though, that cable will very likely fail to load any SysEx, it well may be used to get short MIDI messages from the MIDI input (i.e. you can do a recording and so on).
I think I've got it now - I've installed libusb in filter mode, still using usb-midi.dll in the registry, so now I have standard windows driver functionality, AND sysex out. I changed the name of the device in usb-sender.h to "SYSEX-MIDI" to differentiate between the Windows driver output, and your driver output, and now it TRULY works.
I'm still a little confused as to how filter mode works, but I'm guessing it just passes input or whatever on to the standard Windows driver? Either way, it works now! Sysex dumping from my synth is unreliable at best, but for regular midi notes it does what it's supposed to, and dumping TO the synth is absolutely flawless.
Would you mind if I hosted the edited .dll along with some instructions on my site? I have a feeling this could help out a lot of people using dodgy chinese USB-MIDI interfaces.
Great idea. I think it's best to make a setup package that registers the driver on both 32-bit and 64-bit systems. If it seems problematic, we can adopt the mt32emu driver installer.
wrote:Great idea. I think it's best to make a setup package that registers the driver on both 32-bit and 64-bit systems. If it seems problematic, we can adopt the mt32emu driver installer.
Writing an installer is WAY over my head, but I wrote a guide that I feel pretty adequately explains the procedure.
http://slug.god.jp/sysex-usbmidi/
Let me know if there's something I should change or word differently.