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.

So seems directnuusic messes stuff up? And because spring beats uses it, Thats why it doesn’t work.

Need to see other sources

Okay none of te other virtual midi cables have source at all. i've locate dthe following 64 bit compatible ones.

1) loopbe1 (lousy feedback det3ection, many false positives) you can pay for a source license (!)
2) midi Yoke NG, from the guy who made savihost. no source
3) loopmidi (free, no source)
4) springbeats virtual midi cable (free, with source)

And for NOT free

5) virtual midi cables, and virtual driverless midi cables. both of these are on the ms store, and NOT FREE. no source either.
6) quite a few other raandom and not free cables on the MS store.
7) loopbe30, which lets you shuty of the feedback detection that makes loopbe1 worthless.

loopbe1, sbvmidi, and loopmidi seem to be kernel level drivers (this device is working properly) . while midiyoke ng and vst midi system driver say they have no drivers in device manager.

zaphod77 wrote on Today, 07:37:

Okay none of te other virtual midi cables have source at all. i've locate dthe following 64 bit compatible ones. […]
Show full quote

Okay none of te other virtual midi cables have source at all. i've locate dthe following 64 bit compatible ones.

1) loopbe1 (lousy feedback det3ection, many false positives) you can pay for a source license (!)
2) midi Yoke NG, from the guy who made savihost. no source
3) loopmidi (free, no source)
4) springbeats virtual midi cable (free, with source)

And for NOT free

5) virtual midi cables, and virtual driverless midi cables. both of these are on the ms store, and NOT FREE. no source either.
6) quite a few other raandom and not free cables on the MS store.
7) loopbe30, which lets you shuty of the feedback detection that makes loopbe1 worthless.

loopbe1, sbvmidi, and loopmidi seem to be kernel level drivers (this device is working properly) . while midiyoke ng and vst midi system driver say they have no drivers in device manager.

It seems if we want a LoopBack driver that does not mess with any Midi messages and also compatible with the Midi 2.0 stack of Win11 then only user mode drivers can work.
https://github.com/microsoft/MIDI/issues/1217 … ment-5744987081

So unfortunately the ones with sources in your above list cannot be used without substantial rewrites.

Oh ho ho! Midiyoke NG WORKS.

tested with sendsx, settig both midi in and out to the first midi yoke NG port. 2 bytes, sent, 2 byte received.

https://www.hermannseib.com/programs/myokeng.exe

and yes, i have the new stack.

zaphod77 wrote on Today, 08:01:

Oh ho ho! Midiyoke NG WORKS. […]
Show full quote

Oh ho ho! Midiyoke NG WORKS.

tested with sendsx, settig both midi in and out to the first midi yoke NG port. 2 bytes, sent, 2 byte received.

https://www.hermannseib.com/programs/myokeng.exe

and yes, i have the new stack.

Confirmed!

I have just tried and with myokeng installed FSMP can use the standalone version of S-MU2000 through a single Midi Yoke NG connection to play back 32/48/64-channel Midi files.

I not known when , but I will trying solve and this problem , I want try make in my MIDI Router generate reports about Virtual MIDI ports for system and usage all generated ports )