Reply 2680 of 2697, by zaphod77
have you tried springbeats virtual midi cable?
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.
zaphod77 wrote on Yesterday, 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 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 :
On Error Resume NextOption ExplicitDim objFSO, objShell, file32, file64, bak32, bak64Set objFSO = CreateObject("Scripting.FileSystemObject")Set objShell = CreateObject("WScript.Shell")objShell.Run "cmd /c taskkill /f /im xmplay.exe", 0, Truefile32 = "C:\Windows\System32\dmusic.dll"file64 = "C:\Windows\SysWOW64\dmusic.dll"bak32 = "C:\Windows\System32\dmusic.dll.bak"bak64 = "C:\Windows\SysWOW64\dmusic.dll.bak"If objFSO.FileExists(file32) ThenCall TakeOwnershipAndPermissions(file32)objFSO.MoveFile file32, bak32If objFSO.FileExists(bak32) Then objFSO.DeleteFile bak32, TrueEnd IfIf objFSO.FileExists(file64) ThenCall TakeOwnershipAndPermissions(file64)objFSO.MoveFile file64, bak64If objFSO.FileExists(bak64) Then objFSO.DeleteFile bak64, TrueEnd IfOn Error Resume NextobjShell.Run """" & objShell.CurrentDirectory & "\xmplay.exe""", 1, FalseOn Error GoTo 0Sub TakeOwnershipAndPermissions(filePath)On Error Resume NextDim objWMIService, colFiles, objFile, wmiPathSet objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate, (TakeOwnership, Security)}!\\.\root\cimv2")wmiPath = Replace(filePath, "\", "\\")Set colFiles = objWMIService.ExecQuery("Select * from CIM_DataFile where Name = '" & wmiPath & "'")For Each objFile In colFilesobjFile.TakeOwnership()objShell.Run "icacls """ & filePath & """ /grant *S-1-5-32-544:F", 0, TrueNextOn Error GoTo 0End 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. […]
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. […]
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 )
Please , check this variant , this all work as you need ? Or no ?
https://www.mediafire.com/file/2o8vczkfin0x04 … ta-001.exe/file
How this use ?
1) first run you add ports
2) close
3) secornd run you can use created ports )
I wait results of tests )
Seems like this was writen over-LoopMIDI solution , and me this not like