M-HT wrote on 2026-11-05, 13:38:

I recorded received midi events in MidiPlayer using Event Viewer and compared it to the original midi file. Some sysex events we […]
Show full quote

I recorded received midi events in MidiPlayer using Event Viewer and compared it to the original midi file.
Some sysex events were missing from the recording. When I added them, then it played correctly.
The missing sysex events had the same timestamp as another sysex event.

These events have the same timestamp and the second one is missing in the recording.
F0411016122000002020205363756D6D564D20322E392E3020202061F7
F0411016127F000001F7

These events have the same timestamp and the 2nd, 3rd, 4th, 5th and 6th events are missing in the recording (the 1st, 7th and 8th event are in the recording).
F041101612050008000073F7
F041101612050010010D5DF7
F04110161205001801273BF7
F041101612050020000952F7
F04110161205002801282AF7
F041101612050030010149F7
F041101612050038002023F7
F041101612050040012E0CF7

I have done the exact same experiment on Windows with WMP as the main Midi playing app. I could get all SysEx events from Scummvm.mid played by WMP using Event Viewer:

So it seems the Wine Midi handling layer skips some SysEx messages that are sent at the exact same deltaTime for unknown reasons. It think this should be reported to Wine.
Last time the bug report of realnc was processed rather fast.

BTW, a new test version of FSMP is available that besides some fixes related to the newly released S-MU2000 and S-YXGxx plugins uses a new VST2 Bridge solution instead of JBridge:
VST2Bridge
Contrary to JBridge it is open source and completely free and actually also much more stable. No installation is required, all necessary components are included in the test package.
This way any kind of VST2 plugins with any bit-ness can be used with both the x86 and x64 versions of FSMP.
You should simply copy all files from the test package to your existing MidiPlayer6 folder. Be aware of the correct bit-ness!

https://falcosoft.hu/midiplayer_67_test.zip

I wrote a small program to test the missing sysex events on input port and I was missing some sysex events in Wine but not in Windows.
That was when I had only one buffer added to the port (function midiInAddBuffer). When I added more buffers to the port, then I got all sysex events even in Wine.
Something like this can probably be done in MidiPlayer to get all incoming sysex events in Wine.

M-HT wrote on 2026-11-06, 22:06:

I wrote a small program to test the missing sysex events on input port and I was missing some sysex events in Wine but not in Windows.
That was when I had only one buffer added to the port (function midiInAddBuffer). When I added more buffers to the port, then I got all sysex events even in Wine.
Something like this can probably be done in MidiPlayer to get all incoming sysex events in Wine.

I have tested Midi Player many times with different buffer sizes and amount to get the sweet spot. Older virtual cables like Maple were very finicky in this respect. Currently FSMP uses 128 * 512 byte sized buffers. So I do not think that the single buffer problem applies here.

1procedure TMidiInput.AddSysexBuffer (idx : TPortRange);
2var
3  hdr : PMidiHdr;
4begin
5  GetMem (hdr, sizeof (TMidiHdr));
6  FillChar (hdr^, SizeOf (TMidiHdr), 0);
7  GetMem (hdr^.lpData, 512);
8  hdr^.dwBufferLength := 512;
9  hdr^.dwUser := idx;
10  midiInPrepareHeader (fMidiInHandle [idx], hdr, sizeof (hdr^));
11  midiInAddBuffer (fMidiInHandle [idx], hdr, sizeof (hdr^));
12  fSysexHeaders.Add (hdr);
13end;
14
15....
16
17  for i := 0 to 31 do
18   begin
19      AddSysexBuffer (idx);
20      AddSysexBuffer (idx);
21      AddSysexBuffer (idx);
22      AddSysexBuffer (idx);
23  end;    

This way FSMP can handle many small SysEx messages and also the maximum allowed 64KB message at once.
So I still believe that the problem is Wine's implementation and not FSMP's. FSMP's input handling has been tested with many kinds of inputs from Win9x to Win11 without problems.
Also most likely this is a regression in Wine since earlier Linux users reported problem free working.

M-HT wrote on 2026-11-06, 22:06:

I wrote a small program to test the missing sysex events on input port and I was missing some sysex events in Wine but not in Windows.
That was when I had only one buffer added to the port (function midiInAddBuffer). When I added more buffers to the port, then I got all sysex events even in Wine.
Something like this can probably be done in MidiPlayer to get all incoming sysex events in Wine.

BTW, I have found the problematic part/bug in Wine. It's actually related to how done buffer flags (MHDR_DONE) are handled incorrectly.
This is completely different from what any Windows versions do or ever did.
In the native ALSA MIDI input path Wine can mark a SysEx input buffer as reusable while its MIM_LONGDATA notification is still waiting in Wine’s internal queue.
If an application re-queues the buffer during that interval, the pending callback can receive a MIDIHDR whose byte count has already been reset.

What Wine should do instead:
While Wine holds a MIM_LONGDATA notification in its internal queue, the associated header should remain unavailable for reuse.
At callback dispatch, the header and dwBytesRecorded should still describe the SysEx data that caused that notification.

I you have an account for Wine's bug tracker here are the details that can be reported besides the above general description:

1. Wine marks the header done on the receive thread:
In dlls/winealsa.drv/alsamidi.c, handle_sysex_event() removes the completed header from the input queue, clears MHDR_INQUEUE, sets MHDR_DONE, and queues a notification carrying the same header pointer.

2. Wine delivers the callback on a separate thread:
In dlls/mmdevapi/main.c, notify_thread() dequeues the notification and calls notify_client(), which invokes DriverCallback().

3. Re-queuing the header clears the byte count before the pending callback reads it:
In dlls/winealsa.drv/alsamidi.c, midi_in_add_buffer() accepts the prepared header B because MHDR_INQUEUE is already clear. It then resets the byte count as part of re-queuing.
When original callback runs, it receives the same header pointer and can see zero bytes. The application loses that SysEx message even though Wine received it. Wine source — alsamidi.c, lines 1263–1277

@Edit:
OK, I submitted a bug report here:
https://bugs.winehq.org/show_bug.cgi?id=60715

M-HT wrote on 2026-11-06, 22:06:

I wrote a small program to test the missing sysex events on input port and I was missing some sysex events in Wine but not in Windows.
That was when I had only one buffer added to the port (function midiInAddBuffer). When I added more buffers to the port, then I got all sysex events even in Wine.
Something like this can probably be done in MidiPlayer to get all incoming sysex events in Wine.

About this I known , when I was make MIDI Router , I have same problems , I can solve this only when add 16 ring buffers , but and this not always working correctly , I mean what sysex not lossing , but notes may play with delay or losting , I not known how fix this problem , seems like same problem and Wine creators )

New test version:
https://falcosoft.hu/midiplayer_67_test.zip

Testable features:
1. Besides cross-bitness VST2 plugin support cross-bitness CLAP plugin support has been added. That is both the x86 and x64 versions of FSMP can load both x86 and x64 versions of VST2 and CLAP plugins.
2. Until Wine fixes its above described bug a mitigation has been added to FSMP so that all SyeEx messages should arrive to FSMP from ALSA/Wine. (It seems there is no reaction for the reported bug so far).
3. An experimental fix to file writing in case of Offline mode by disabling async file writes in Offline mode.
@RetroGC: please, test it.

Falcosoft wrote on Yesterday, 13:23:

New test version:
https://falcosoft.hu/midiplayer_67_test.zip

I can report this works now with ScummVM and the Monkey titles.
Thanks @M-HT and @Falcosoft!!!
Im sorry i could not assist you (FSoft) in the way M-HT did. Im so happy i can stay with FSMP!!!!!!!!!!

Small bugreport from my side:
Trying the 64 bit build with wine/proton throws those errors:
(1)On enabling Bassmidi: cannot load right version of bass.dll and/or bassmidi.dll, so Bassmidi output cannot be enabled.
(2)On Settings: Multimedia System Error 11 - Invalid parameter passed in mixer GetLineControls.

DOSShark wrote on Yesterday, 20:38:

Small bugreport from my side: Trying the 64 bit build with wine/proton throws those errors: (1)On enabling Bassmidi: cannot load […]
Show full quote

Small bugreport from my side:
Trying the 64 bit build with wine/proton throws those errors:
(1)On enabling Bassmidi: cannot load right version of bass.dll and/or bassmidi.dll, so Bassmidi output cannot be enabled.
(2)On Settings: Multimedia System Error 11 - Invalid parameter passed in mixer GetLineControls.

1. And previous 64-bit versions like the official version 6.6 worked?
Notice that first you have to download the official 64-bit version from here:
https://falcosoft.hu/midiplayer_66_x64.zip
Then you have to overwrite the files in the unpacked 64-bit MidiPlayer6 folder with the ones you can find in the x64 folder of the 6.7 test version.
The test version zip files are NOT full releases! They only contain the differences/changed files.

2. This is a very old Wine bug that affected all previous versions as well (including the 32-bit versions of FSMP). It's because the classic mixer API is not implemented properly in Wine.
But it does not affect proper working in Bassmidi/VSTi output mode that does not use the Windows mixer API.

Oh yeah - extracting the full 64 bit version with the update over it solved all bugs - silly me 😁