Roland User wrote on 2026-09-20, 22:07:

Thank you )
In all , is it possible create program whitch will be report to Windows about available how much MIDI portrs in system without use dll , drv , sys files ? I mean what we do run software and in system ports appear via which we can translate MIDI streaming and via which we can get MIDI streaming , but if close application , so all ports erasing from system , so do possible ?

No, you have to write or use a driver component to do this. BTW, even your current beta application needs to use and actually uses a driver component, namely teVirtualMIDI to create ports.
This is the same driver component used by LoopMidi. So If you want a permanent virtual cable you should use LoopMidi instead. You will get the same engine.

And this I want avoid , in ideal situation program must create ports at all without dirvers , how application create files or folders ) , and I want understandin , this generally possible or this impossible )

Roland User wrote on 2026-09-20, 22:24:

And this I want avoid , in ideal situation program must create ports at all without dirvers , how application create files or folders ) , and I want understandin , this generally possible or this impossible )

As I said no, it is not possible to create even temporary Midi ports without a driver component.

Thank you )
Unfortunately I do not understand in drivers , for me even software logic not always cleary )
But I was try )
By the way , what I do not like in solution from Hermann Seib , so that in he solution limit quantity ports and names ports hard limits in names , him solution may be much better if Hermann Seib added options free quantity of ports and free names for ports ) and then this solution will irreplaceable )

Still me very interesting , in what way was write this
https://sourceforge.net/projects/munt/files/OldFiles/ what when I add this in

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"midi(number)i"="filename from MUNT"

or

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]
"midi(number)i"="filename from MUNT"

and we recive MT-32 Emulator device , how I can do same , but for multiple ports ?

Or maybe you create this solution with the possibility add up to 256 I/O MIDI devices with selectable device name )

Roland User wrote on 2026-09-21, 07:29:

Still me very interesting , in what way was write this https://sourceforge.net/projects/munt/files/OldFiles/ what when I add th […]
Show full quote

Still me very interesting , in what way was write this
https://sourceforge.net/projects/munt/files/OldFiles/ what when I add this in

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"midi(number)i"="filename from MUNT"

or

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]
"midi(number)i"="filename from MUNT"

and we recive MT-32 Emulator device , how I can do same , but for multiple ports ?

Or maybe you create this solution with the possibility add up to 256 I/O MIDI devices with selectable device name )

Multimedia client drivers (like your Munt example) can create multiple ports within a single driver. E.g. VST Midi driver (that is also a Multimedia client driver) hosts 2 ports: VST MIDI Synth port A and VST MIDI Synth port B.
You can study the source code of the driver if you want to know more:
https://github.com/Falcosoft/vstdriver/blob/m … r/winmm_drv.cpp

But please, be aware that this is NOT the topic of your Midi related learning and experimenting projects. Open a new topic for such questions.

Good , I understand you ) simply firstly I wanted create MIDI cable for solve problem about whitch sayd zaphod77 , but morre flexible )
Thank you )

Roland User wrote on 2026-09-21, 07:55:

Good , I understand you ) simply firstly I wanted create MIDI cable for solve problem about whitch sayd zaphod77 , but morre flexible )

You will not be able to. Because:
1. With the help of user mode installable client drivers you cannot create/delete ports dynamically from your app while the OS is running. The number of ports are defined by the driver.
2. To create/delete ports dynamically at runtime you need a kernel driver component (like teVirtualMIDI). But as we have just discovered recently (and also confirmed by Pete Brown from MS) kernel components currently discard/drop Midi messages that are not known by them.
So you cannot transfer 2-byte 'F5 nn' messages when kernel components are involved. So currently you cannot create a 'more flexible' version of what we were talking about with zaphod77.
Midiyoke NG loopack driver is as good and flexible as currently possible.

Yes , I agry , but the only thing what not enough in Midiyoke NG loopack driver , this quantity of ports and ports name ) and I was trying fix this )

Roland User wrote on 2026-09-21, 08:23:

Yes , I agry , but the only thing what not enough in Midiyoke NG loopack driver , this quantity of ports and ports name ) and I was trying fix this )

You cannot 'fix this'.

Something I noticed when using the SMU2000 plugin (VST2 version) under Windows 11 x64 with the MIDI Player (v6.6):
Loading the plugin is not an issue, but when trying to unload it, the whole process gets stuck and I can only break free by forcefully shutting down FSMP. If I want to load a different plugin I basically have to edit the .ini file manually for now. No idea what's happening here, but would be great if it got fixed. File size cannot be the issue since the new MU VSTs are over 80 MB in size (SMU2000 is currently around 9 MB) and don't behave like this.

Trelokk wrote on 2026-10-08, 11:27:

Something I noticed when using the SMU2000 plugin (VST2 version) under Windows 11 x64 with the MIDI Player (v6.6):
Loading the plugin is not an issue, but when trying to unload it, the whole process gets stuck and I can only break free by forcefully shutting down FSMP. If I want to load a different plugin I basically have to edit the .ini file manually for now. No idea what's happening here, but would be great if it got fixed. File size cannot be the issue since the new MU VSTs are over 80 MB in size (SMU2000 is currently around 9 MB) and don't behave like this.

Hi,
It's a threading issue and a mitigation has already been integrated into the new test version of FSMP:
https://falcosoft.hu/midiplayer_67_test.zip

Excellent! Time to upgrade early for me then, I guess. ^^ Thanks!

Hi,
Spessasus found a very interesting SC-8850 specific Midi file:

https://github.com/tarboh/S-MU2000/issues/82# … ment-5973171324

This post is unrelated to Spessasus original problem with this Midi file. The point is that Tarboh identified SC-8850 specific LCD bitmap messages in this Midi file. I tried to find references in the official SC-8850 manual but I could only find the description of the classic SC-55/88/Pro low-res LCD Bitmap messages. But this Midi file contains so many kinds of hi-res LCD Bitmap messages that the logic could be easily reverse-engineered. Contrary to the low-res 16x16 LCD Bitmap messages these hi-res messages can address 160x64 resolution LCD bitmaps. Thus the final bitmap can look much more detailed:

I have added support for these hi-res LCD Bitmap messages to the new test version of FSMP:
https://falcosoft.hu/midiplayer_67_test.zip

Here is a test video:
https://youtu.be/q9sPNTOMk3o?si=LmPEn1MUq6j9pgSz

It's fixed, as it seems. 😀