Open DJShades opened 10 years ago
Update: Just done a bit of digging and found out that the inability to detect virtual serial ports was a problem with QextSerialPort (http://code.google.com/p/qextserialport/issues/detail?id=54) however, it appears to have been fixed. Hopefully, this will just mean "fixing" HMS will be a matter of swapping the QextSerialPort libraries and recompiling... but when has life ever been that simple? :D lol
Oops, clicked on close button accidentally.
Hi DJShades,
Good find, that looks like what we'll need! I'll try and rebuild for a new release shortly.
I just have one other question, what specific virtual serial port emulator is not working? If it's freely available then I'll install it so I can confirm the issue and verify the fix.
Cheers,
Angus
Hi Angus,
Thanks for your reply.
The virtual serial port emulator I've been using is available free from http://eterlogic.com/Products.VSPE.html However, after doing a little more digging I think I know a little more about the problem.
VSPE doesn't create virtual ports that appear in Windows Device Manager leading me to believe that it doesn't install Kernal Mode (if thats the right term) drivers for the ports, it employs some other kind of trickery. I discovered this while, out of curiosity, testing out another virtual port emulator (com0com/Null-modem emulator - http://sourceforge.net/projects/com0com/) to see if the same problem occured with other emulators...
I found that com0com can also create serial ports that don't appear in HMS (and they also have their own custom entry in the Windows Device Manager, not under the "ports" list). However, as soon as I changed the ports in com0coms settings to "use Ports Class" the custom devices were removed and new drivers were installed for "devices" that do appear in Windows Device Managers "ports" list. These ports do appear in HMS.
So, if I had to hazard a guess, the old version of QextSerialPort has problems, on Windows at least, detecting ports that aren't listed in the ports section of Windows Device Manager. Hopefully, the fix will be as simple as rebuilding HMS with the latest QextSerialPort libraries.
(I apologise if the terminology isn't quite correct and I hope you understand what I mean)
Fortunately, due to testing a different virtual port emulator I found that com0com is actually better for my needs (the ports, being Kernal Mode driven, survive a re-boot, and I thus avoid having to manually start an emulator every time I need them... or, better yet, by people who are unable to follow simple instructions! :D)
Even though I have found a fix for my specific problem hopefully you'll still judge it worth updating HMS as it is, by a large margin, the best serial-to-MIDI bridge out there (purely for the fact that it saves its settings and doesn't require any further action to start the bridge beyond actually starting the program... other bridges either require manually setting them up every time they're run or require a button to be clicked to activate the bridge once the app has loaded). Others, less curious than myself, might instantly dismiss the problem as being that of HMS itself and will miss out on a fantastic little app.
Apologies for the long, rambling, post! :D
Best regards,
Shades
I'm currently trying to find the best combination of software to control a MIDI enabled application from a lighting program - Martin LightJockey. However, while Martin LightJockey can output MIDI data (or any arbitrary string, decimal or hex commands) it can only do so via a serial port. Therefore I have to use a serial port emulator to create two linked virtual serial ports, to re-route the data back internally. Martin Lightjockey is connected to one side of the virtual serial port pair (COMx) while a serial-to-MIDI bridge is connected to the other (COMy). The serial-to-MIDI bridge is then connected to a MIDI loopback device (MIDI-Yoke) to which the target MIDI enabled application connects.
Hairless Midi-Serial (HMS) would seem to fit the bill perfectly as part of this software chain as its the only software of its type that I've tried - and I've tried a few - that either doesn't require settings to be entered every time it is started or doesn't require a "connect" button to be manually pressed each time it is run. With HMS I could auto-start it when Windows boots and forget about it.
I say would and could because HMS (the latest compiled version for Windows) appears to be unable to detect some virtual serial ports. However, it does detect the (virtual) serial ports created by my laptops internal Bluetooth device. Other serial-to-MIDI bridges I've tried successfully detect all COM ports so this problem seems unfortunately exclusive to HMS.
I appreciate that HMS hasn't been updated for a little while but hopefully this issue can be looked into as I really would prefer to use HMS because, being a single executable, it doesn't have an dependencies and it can be run at boot, once setup, with no other user interaction..
Thanks in advance :)