have you tried springbeats virtual midi cable?

zaphod77 wrote on 2026-09-18, 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.

https://bitbucket.org/springbeats/sbvmidi/src/master/

zaphod77 wrote on Yesterday, 00:23:

the original message type is send directly over the rs232 serial bus. it only works there. […]
Show full quote

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.

https://bitbucket.org/springbeats/sbvmidi/src/master/

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 Yesterday, 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 )

I tested by using looping the cable directly for out to in inside of the sendsysex app and get different results.

sbvmidi is using directmusic. and appears to use it to validate the midi message.

https://bitbucket.org/springbeats/sbvmidi/src … m.cpp#lines-319

maybe one of you can figure out how to build a virtual midi cable that doesn't do that?

If you have corrupted sysex via DirectMusic , so this problem can not will solved , I get this problem when trying use XMPlay with plugin in_midi.dll , and when I tryed use DirectMusic , I always was get not correct result , because I write DirectMusic remover :

1On Error Resume Next
2Option Explicit
3Dim objFSO, objShell, file32, file64, bak32, bak64
4Set objFSO = CreateObject("Scripting.FileSystemObject")
5Set objShell = CreateObject("WScript.Shell")
6objShell.Run "cmd /c taskkill /f /im xmplay.exe", 0, True
7file32 = "C:\Windows\System32\dmusic.dll"
8file64 = "C:\Windows\SysWOW64\dmusic.dll"
9bak32  = "C:\Windows\System32\dmusic.dll.bak"
10bak64  = "C:\Windows\SysWOW64\dmusic.dll.bak"
11If objFSO.FileExists(file32) Then
12Call TakeOwnershipAndPermissions(file32)
13objFSO.MoveFile file32, bak32
14If objFSO.FileExists(bak32) Then objFSO.DeleteFile bak32, True
15End If
16If objFSO.FileExists(file64) Then
17Call TakeOwnershipAndPermissions(file64)
18objFSO.MoveFile file64, bak64
19If objFSO.FileExists(bak64) Then objFSO.DeleteFile bak64, True
20End If
21On Error Resume Next
22objShell.Run """" & objShell.CurrentDirectory & "\xmplay.exe""", 1, False
23On Error GoTo 0
24Sub TakeOwnershipAndPermissions(filePath)
25On Error Resume Next
26Dim objWMIService, colFiles, objFile, wmiPath
27Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate, (TakeOwnership, Security)}!\\.\root\cimv2")
28wmiPath = Replace(filePath, "\", "\\")
29Set colFiles = objWMIService.ExecQuery("Select * from CIM_DataFile where Name = '" & wmiPath & "'")
30For Each objFile In colFiles
31objFile.TakeOwnership()
32objShell.Run "icacls """ & filePath & """ /grant *S-1-5-32-544:F", 0, True
33Next
34On Error GoTo 0
35End Sub

this solution will force usage only standard devices without DirectMusic )
and only after this , I start get correct result , maybe you this also help )

Roland User wrote on Yesterday, 19:17:

If you have corrupted sysex via DirectMusic , so this problem can not will solved , I get this problem when trying use XMPlay with plugin in_midi.dll , and when I tryed use DirectMusic , I always was get not correct result , because I write
...

We are not talking about SysEx messages right now. The mentioned problematic 'F5 nn' messages are NOT SysEx messages but common system messages. They are very different.

zaphod77 wrote on Yesterday, 14:20:

...
maybe one of you can figure out how to build a virtual midi cable that doesn't do that?

I'm thinking about writing a purely user mode installable client loopback driver. But unfortunately I do not have much free time nowadays.