have you tried springbeats virtual midi cable?
zaphod77 wrote on Yesterday, 23:22:have you tried springbeats virtual midi cable?
Thanks, I have just tried it.
1. I recommend this driver to no one because of the shady practice of redirecting users to a purchase site where you have to spend 10 minutes to find out how to download this driver really for free...
2. This is the strangest implementation of how 'F5 nn' messages can be ruined. This driver extends the 2nd byte of the original message to be part of a Note Off message. The Note Off status byte is hallucinated from nowhere by this driver...
the original message type is send directly over the rs232 serial bus. it only works there.
it's very odd that virtual midi ports much with things so much, when they actually need to just pass it through, and let the device handle it.
that said, the source is available, so you can try reading it and figure out where it's going wrong.
zaphod77 wrote on Today, 00:23:the original message type is send directly over the rs232 serial bus. it only works there. […]
the original message type is send directly over the rs232 serial bus. it only works there.
it's very odd that virtual midi ports much with things so much, when they actually need to just pass it through, and let the device handle it.
that said, the source is available, so you can try reading it and figure out where it's going wrong.
Hi,
1. Yes, but in theory It can work anywhere if the driver do not interfere with the message but simply transfer it the in the same form as it has been delivered by the client. WinMM itself can do this without problems. VST2 and CLAP can also do this.
2. The problem with modified kernel drivers is that they have to be signed some way in order to be usable on modern Windows versions by average users.
Okay, the issue here appears to be windows itself messing with stuff, strangely enough.
check the source yourself. you see that it calls a lot of windows functions that aren't defined in the source, and those seem to be what's messing with the F5, because it's not a standard midi byte.
Thank you ) , I firstly try find bug or error in myself solution , that so why I asked you ) , now when I understand taht problem not in my solution , I known what all maked correctly )
zaphod77 wrote on Today, 03:35:Okay, the issue here appears to be windows itself messing with stuff, strangely enough.
check the source yourself. you see that it calls a lot of windows functions that aren't defined in the source, and those seem to be what's messing with the F5, because it's not a standard midi byte.
Hi,
It's very interesting since as I have told you the Windows Midi 1.x stack itself handles these messages perfectly: that is they can be sent by either midiOutShortMsg() or midiOutLongMsg() and can be received by devices or drivers. Otherwise VST MIDI driver could not handle these messages either.
And it seems these kernel mode Midi loopback drivers do not handle (and ruin) these messages the same way. E.g. LoopMidi does not create a fake Note Off event form the 2nd byte but simply discards/rejects it:
And this not all , in WinMM MIDI stack available something else strange... for example , avaialble command all notes off or MIDI panic , but WinMM in typical logic this action whitch zero velocity , this you can see in old MS-DOS games for example Nascar Racing if do run game from DOSBOX-X or in press stop in Windows Media Player , I noticed what sent panic or zero velocity in WMP and psent panic or zero velocity in XMPlay with in_midi.dll version 3.07 , not identicaly )
