This is probably an not to here share , but I random recording MIDI per MPU-401 and so what this pure AdLib OPL synth , moreover so I can record only title music )
Now all music from MPU-401 out )
I not known as this It turned out to be do , but I record this music for fans this game
Very beautiful music if you listen on Roland MT-32 synth

Translation provided by Grieferus Runglish-to-English Translation Service.

This is probably something I shouldn't share here, but I've recorded random MIDIs through MPU-401 and so, this is pure AdLib OPL synth, although I can only record title music.
And now I release all the music from MPU-401.
I don't know how I've managed to do that, but I've recorded this music for the fans of this game.
(The last sentence doesn't need translation).

Roland User wrote on 2024-12-06, 01:06:

This is probably an not to here share , but I random recording MIDI per MPU-401 and so what this pure AdLib OPL synth , moreove […]
Show full quote

This is probably an not to here share , but I random recording MIDI per MPU-401 and so what this pure AdLib OPL synth , moreover so I can record only title music )
Now all music from MPU-401 out )
I not known as this It turned out to be do , but I record this music for fans this game
Very beautiful music if you listen on Roland MT-32 synth

Thanks for your sharing. Yes, they are nice ones.

Falcosoft wrote on 2024-12-05, 18:31:

Hi, Now I see what is happening. When you play the RMI file with Midi Player your selected channel is 16 but channel 16 is not u […]
Show full quote

Abu Brandino wrote on 2024-12-05, 14:06:

Falcosoft wrote on 2024-12-02, 07:23:

Hi, I have just tested and this is not true. RMI files work perfectly and there is no general problem with sustain controller. I […]
Show full quote

Hi,
I have just tested and this is not true. RMI files work perfectly and there is no general problem with sustain controller. I have tested bachsrb.rmi and mozart.rmi.
Here is a video about my testing:
https://youtu.be/mKkpcOnr_qg

The problem with your report is:
1. You have not told yet what Midi output you used. I have tested both Bassmidi and MS GS Soft Synth and both worked perfectly.
2. Neither bachsrb.rmi nor mozart.rmi actually uses sustain controller (CC#64). Sustain is disabled all along (CC#64 = 0). So it is hard to tell what you are talking about.

So overall it seems the problem is not with Midi player and you should tell me how to reproduce your problem exactly.
That is:
1. What kind of Midi output you used.
2. Excatly what Midi file(s) you used and what I should listen to. The best would be if you could attach your problematic Midi file(s) since there can be different versions that could prevent meaningful testing.

https://youtu.be/pQCTIskVJEQ

Here I've demonstrated what I mean, hopefully it makes it clear. If you need any further information please do ask. The description has some info too. I will attach the RMI used here.

Hi,
Now I see what is happening. When you play the RMI file with Midi Player your selected channel is 16 but channel 16 is not used by your file so it is not showing activity. That is why you cannot see the activated sustain controllers either since they are not sent to channel 16 but to channel 1 and channel 2.
When you play the RMI file with Windows Media Player through Midi player's Midi input you use the Channel -> 'Follow' option. This way all the incoming messages change the active channel. That's why you always see the incoming sustain controller messages (and also as the active channel changes wildly) . The Channel -> Follow option is not recommended for normal playback through Midi input since it causes overhead and can cause timing problems. It is mainly for real time jamming with a Midi keyboard when it is not always obvious what channel(s) are used by the keyboard. If you set the Channel option to 'Do not follow' you will get the same behavior as during Midi Player's playback. That is the active visible channel is not changing wildly because of incoming Midi messages.
Here is my demonstration video that shows that sustain controllers are also active when the RMI file is played by Midi Player but first you have to select the active channels (channel 1 or channel 2) manually to see them:
https://youtu.be/qgIhldsocMM

So once again Midi player plays your file properly. The sustain controller messages are sent but you have to learn how to use the user interface to see them.

I see what you mean but it doesn't seem like the pan knob changes and it sounds like the panning of the audio only works with the WMP. Can you confirm that for me?

Sorry I'm a noob at your program, but I actually would appreciate a manual to it. Do you have one?
Thanks boss!

Abu Brandino wrote on 2024-12-07, 12:25:

I see what you mean but it doesn't seem like the pan knob changes and it sounds like the panning of the audio only works with th […]
Show full quote

Falcosoft wrote on 2024-12-05, 18:31:

Hi, Now I see what is happening. When you play the RMI file with Midi Player your selected channel is 16 but channel 16 is not u […]
Show full quote

Abu Brandino wrote on 2024-12-05, 14:06:

https://youtu.be/pQCTIskVJEQ

Here I've demonstrated what I mean, hopefully it makes it clear. If you need any further information please do ask. The description has some info too. I will attach the RMI used here.

Hi,
Now I see what is happening. When you play the RMI file with Midi Player your selected channel is 16 but channel 16 is not used by your file so it is not showing activity. That is why you cannot see the activated sustain controllers either since they are not sent to channel 16 but to channel 1 and channel 2.
When you play the RMI file with Windows Media Player through Midi player's Midi input you use the Channel -> 'Follow' option. This way all the incoming messages change the active channel. That's why you always see the incoming sustain controller messages (and also as the active channel changes wildly) . The Channel -> Follow option is not recommended for normal playback through Midi input since it causes overhead and can cause timing problems. It is mainly for real time jamming with a Midi keyboard when it is not always obvious what channel(s) are used by the keyboard. If you set the Channel option to 'Do not follow' you will get the same behavior as during Midi Player's playback. That is the active visible channel is not changing wildly because of incoming Midi messages.
Here is my demonstration video that shows that sustain controllers are also active when the RMI file is played by Midi Player but first you have to select the active channels (channel 1 or channel 2) manually to see them:
https://youtu.be/qgIhldsocMM

So once again Midi player plays your file properly. The sustain controller messages are sent but you have to learn how to use the user interface to see them.

I see what you mean but it doesn't seem like the pan knob changes and it sounds like the panning of the audio only works with the WMP. Can you confirm that for me?

Sorry I'm a noob at your program, but I actually would appreciate a manual to it. Do you have one?
Thanks boss!

Hi,
1. As for pan controllers: the situation is the same as in case of sustain controllers. In Beethoven's Fur Elise.rmi the pan position does not change on any channels during playback. At the very beginning It is set to right 3o on channel 1 and set to left 30 on channel 2. You only see the panning changes in case of WMP (through Midi Input) since you have Channel -> 'Follow' option selected. This way the active channel changes on incoming Midi message including Note On/Off messages. So it is just an illusion since you see the actual values of different channels. As I said before you should change Channel -> 'Follow' option to Channel -> 'Do not Follow' for normal playback through Midi Input (Channel -> 'Do not Follow' is the default anyway). You should only select Channel -> 'Follow' option if you are using an attached Midi Keyboard and you would like to determine what channel value the Midi keyboard is using.

2. There is no manual but there is a Howto/FAQ section with video tutorials:
http://falcosoft.hu/midiplayer_howto.html
The Channel -> Follow/Override/Do not Follow options are explained at section 9:
http://falcosoft.hu/midiplayer_howto.html#a9

Falcosoft wrote on 2024-12-07, 15:33:

Hi, 1. As for pan controllers: the situation is the same as in case of sustain controllers. In Beethoven's Fur Elise.rmi the pa […]
Show full quote

Abu Brandino wrote on 2024-12-07, 12:25:

I see what you mean but it doesn't seem like the pan knob changes and it sounds like the panning of the audio only works with th […]
Show full quote

Falcosoft wrote on 2024-12-05, 18:31:

Hi, Now I see what is happening. When you play the RMI file with Midi Player your selected channel is 16 but channel 16 is not u […]
Show full quote

Hi,
Now I see what is happening. When you play the RMI file with Midi Player your selected channel is 16 but channel 16 is not used by your file so it is not showing activity. That is why you cannot see the activated sustain controllers either since they are not sent to channel 16 but to channel 1 and channel 2.
When you play the RMI file with Windows Media Player through Midi player's Midi input you use the Channel -> 'Follow' option. This way all the incoming messages change the active channel. That's why you always see the incoming sustain controller messages (and also as the active channel changes wildly) . The Channel -> Follow option is not recommended for normal playback through Midi input since it causes overhead and can cause timing problems. It is mainly for real time jamming with a Midi keyboard when it is not always obvious what channel(s) are used by the keyboard. If you set the Channel option to 'Do not follow' you will get the same behavior as during Midi Player's playback. That is the active visible channel is not changing wildly because of incoming Midi messages.
Here is my demonstration video that shows that sustain controllers are also active when the RMI file is played by Midi Player but first you have to select the active channels (channel 1 or channel 2) manually to see them:
https://youtu.be/qgIhldsocMM

So once again Midi player plays your file properly. The sustain controller messages are sent but you have to learn how to use the user interface to see them.

I see what you mean but it doesn't seem like the pan knob changes and it sounds like the panning of the audio only works with the WMP. Can you confirm that for me?

Sorry I'm a noob at your program, but I actually would appreciate a manual to it. Do you have one?
Thanks boss!

Hi,
1. As for pan controllers: the situation is the same as in case of sustain controllers. In Beethoven's Fur Elise.rmi the pan position does not change on any channels during playback. At the very beginning It is set to right 3o on channel 1 and set to left 30 on channel 2. You only see the panning changes in case of WMP (through Midi Input) since you have Channel -> 'Follow' option selected. This way the active channel changes on incoming Midi message including Note On/Off messages. So it is just an illusion since you see the actual values of different channels. As I said before you should change Channel -> 'Follow' option to Channel -> 'Do not Follow' for normal playback through Midi Input (Channel -> 'Do not Follow' is the default anyway). You should only select Channel -> 'Follow' option if you are using an attached Midi Keyboard and you would like to determine what channel value the Midi keyboard is using.

2. There is no manual but there is a Howto/FAQ section with video tutorials:
http://falcosoft.hu/midiplayer_howto.html
The Channel -> Follow/Override/Do not Follow options are explained at section 9:
http://falcosoft.hu/midiplayer_howto.html#a9

Thank you so much boss. Really appreciate the explanation. I guess placebo really is a real thing haha.
Great program as always, still using it as my main DOSBox MIDI processor.

One final thing...concerning the 'MIDI In' section of the settings. Every time I turn on my DAC for my headset/speakers it switches from my internal MIDI port from loopMIDI to the DAC's. Is there a way to prevent that auto switch? The only way to avoid it currently is to have the DAC switched on before the BIOS boots into Windows.

Abu Brandino wrote on 2024-12-08, 00:12:

One final thing...concerning the 'MIDI In' section of the settings. Every time I turn on my DAC for my headset/speakers it switches from my internal MIDI port from loopMIDI to the DAC's. Is there a way to prevent that auto switch? The only way to avoid it currently is to have the DAC switched on before the BIOS boots into Windows.

Yes, Windows does not necessarily preserve the order of Midi In/Out Devices when a device is added or removed.
Here is a new test version that tries to circumvent this problem. Only the main exe files are included so you have to replace the current ones with the new ones. Be aware of the bitness. Please, try it and report back:
https://falcosoft.hu/midiplayer_65_test.zip

As I can do RND mode in MIDI ?
If I set pan value 0 - I recive only left channel , if I set pan value as 127 I recive only right channel , but as set 0 for randomize channels in MIDI file ? Sequancers with this not work and any value 0 or -63 Identical

Roland User wrote on 2024-12-09, 00:26:

As I can do RND mode in MIDI ?
If I set pan value 0 - I recive only left channel , if I set pan value as 127 I recive only right channel , but as set 0 for randomize channels in MIDI file ? Sequancers with this not work and any value 0 or -63 Identical

Hi,
You cannot set random(RND) panpot value with the help of controller (CC#10) messages. This only works with the help of SysEx messages.
Panpot range is somewhat unbalanced in the sense that the left range is bigger by one (the range is from -64 to +63). the leftmost position -64 is assigned to value 0 and the rightmost position +63 is assigned to 127.
But when value 0 is sent through controller 10 (CC#10) the value 0 is interpreted the same way as value 1( that means -63). But when value 0 (-64) is sent through SysEx messages the value 0 is interpreted as random (RND).
Here is the SysEx message that sets random(RND) panpot value on channel 1:

1F0 41 10 42 12 40 11 1C 00 13 F7   

And here is the SysEx message that sets random(RND) panpot value on channel 2:
(this is what you need for the Midi in your video)

1F0 41 10 42 12 40 12 1C 00 12 F7 

Falcosoft wrote on 2024-12-08, 12:07:

Yes, Windows does not necessarily preserve the order of Midi In/Out Devices when a device is added or removed. Here is a new tes […]
Show full quote

Abu Brandino wrote on 2024-12-08, 00:12:

One final thing...concerning the 'MIDI In' section of the settings. Every time I turn on my DAC for my headset/speakers it switches from my internal MIDI port from loopMIDI to the DAC's. Is there a way to prevent that auto switch? The only way to avoid it currently is to have the DAC switched on before the BIOS boots into Windows.

Yes, Windows does not necessarily preserve the order of Midi In/Out Devices when a device is added or removed.
Here is a new test version that tries to circumvent this problem. Only the main exe files are included so you have to replace the current ones with the new ones. Be aware of the bitness. Please, try it and report back:
https://falcosoft.hu/midiplayer_65_test.zip

I'll give it a go and report back if the issue is solved.

Falcosoft wrote on 2024-12-08, 12:07:

Yes, Windows does not necessarily preserve the order of Midi In/Out Devices when a device is added or removed. Here is a new tes […]
Show full quote

Abu Brandino wrote on 2024-12-08, 00:12:

One final thing...concerning the 'MIDI In' section of the settings. Every time I turn on my DAC for my headset/speakers it switches from my internal MIDI port from loopMIDI to the DAC's. Is there a way to prevent that auto switch? The only way to avoid it currently is to have the DAC switched on before the BIOS boots into Windows.

Yes, Windows does not necessarily preserve the order of Midi In/Out Devices when a device is added or removed.
Here is a new test version that tries to circumvent this problem. Only the main exe files are included so you have to replace the current ones with the new ones. Be aware of the bitness. Please, try it and report back:
https://falcosoft.hu/midiplayer_65_test.zip

Unfortunately, fix no worky. Still same issue.

Abu Brandino wrote on 2024-12-13, 22:43:

...
Unfortunately, fix no worky. Still same issue.

Try it again with this version (download location is the same):
https://falcosoft.hu/midiplayer_65_test.zip

Thank you ) now I can test MIDI files with randomize panning )

Hello Zoltan
Can I please thank you for all your work on the x86 and x64 versions of the FSMP, which I have used for a while now with the Roland SCVA (RIP now) and Yamaha SYXG50.

Would you consider porting your software to the WinARM64 platform? I appreciate this is not a trivial task but Microsoft have tried to make it as easy as possible in Visual Studio. Although x64 is going nowhere, it also provides another home for your software in the future.

dharmOS wrote on 2024-12-17, 11:57:

Hello Zoltan
Can I please thank you for all your work on the x86 and x64 versions of the FSMP, which I have used for a while now with the Roland SCVA (RIP now) and Yamaha SYXG50.

Would you consider porting your software to the WinARM64 platform? I appreciate this is not a trivial task but Microsoft have tried to make it as easy as possible in Visual Studio. Although x64 is going nowhere, it also provides another home for your software in the future.

Hi,
Midi Player has nothing to do with Microsoft's development tools so unfortunately nothing that is Visual Studio related is relevant.
Currently no Delphi version can output binaries for Windows ARM64.
But I do not consider the lack of a native ARM64 version a serious problem since MidiPlayer has no driver components so both the x86 and the x64 versions of Midi Player should work without problems under ARM based Windows.

Thank you for explaining this. I was not aware that you used Delphi. It does work in x64 emulation mode, just slowly... 😮)

dharmOS wrote on 2024-12-17, 14:01:

Thank you for explaining this. I was not aware that you used Delphi. It does work in x64 emulation mode, just slowly... 😮)

Hi,
I have never tried it but it's hard to believe that Midi Player runs so slow on ARM64 since it runs fairly fast even on a 20+ years old 1GHz Athlon with 512MB RAM. So on a modern ARM64 CPU even if it works at 1/4 of its native speed because of emulation Midi Player should run faster than on a 1GHz Athlon.
Since you mentioned you use SC-VA and S-YXG50 I think VSTi plugins themselves could be the main reason for slow operation.
BTW, with a hypothetical native ARM64 version of MIDI Player you could not use any x86/x64 VSTi plugins such as SC-VA or S-YXG50.

Hi Zoltan )
I often ask you as what as make in MIDI , I shared MIDI files from F-29 Retaliator whitch I can extract and record ) but have problem ) this MIDI files only for MT-32 , I remember what previously was be VDMSound and MIDI converter from MT-32 to GM and from GM to MT-32 , this method was be rude but still.. if possible , you can do same converter only for win32 , simply as I remember , converter was 16 bit and work only Windows 32 bit for example Windows 9x or Windows XP with DOS emulation )

I'm about this ) this possible do automaticly ? If yes and not hard , please , create program for this task )

Hi Zoltan,

Can I request dark mode for FSMP6? For example the background could be a nice #333 while text could be #ccc.

Also, if possible, an option to render a file via BASS offline (not real-time as it can lag sometimes and takes a long time for long files) would be greatly appreciated!

Spesek wrote on Today, 16:39:

Hi Zoltan,

Can I request dark mode for FSMP6? For example the background could be a nice #333 while text could be #ccc.

Also, if possible, an option to render a file via BASS offline (not real-time as it can lag sometimes and takes a long time for long files) would be greatly appreciated!

Hi,
1. Win32 programming is not like web programming. There is no such thing as css in case of Win32 controls. The colors of Win32 controls by default are defined by the system wide themes. You can override the default colors either with a per control method (tedious work) or using some kind of 'theme framework'. For modern/metro applications Microsoft provides such theme framework integrated that can automatically use the OS provided dark theme settings but for pure Win32 applications MS does not provide such. There are alternatives like 'VCL styles' for Delphi applications but showing that writing such a theme library is not a trivial task it is still buggy (despite the fact that it has been developed for more than 10 years).
There are alternative approaches for Win32 apps like this one:
https://github.com/ChGen/DarkEnforcer?tab=readme-ov-file
It forces all Win32 apps to dark mode but as the authors themselves admit :

"This requires a lot of work to be stable and universal, so its still a prototype. This is done by combination fo Win32 global hooks, Win32 Controls subclassing and some UXtheme API and also few other things, including undocumented APIs."

You can also use Midi Player in 'dark mode' currently by using the legacy Windows dark themes (known as high contrast modes):

2. Direct rendering by Bassmidi is only possible if you send the Midi file directly to Bassmidi, meaning such direct rendering would bypass the whole parser/engine of Midi Player. Custom controller/SysEx settings and other overrides would not apply meaning it could sound completely differently compared to real-time playback by Midi Player.
Such direct rendering function is available e.g. in Coolsoft's VMS if you need it anyway:
http://coolsoft.altervista.org/en/virtualmidisynth
BTW, recording should not lag unless the playback is also lagging. And when the playback is lagging it means there are some more serious problems that should be fixed anyway. Maybe the lagging is related to using FSMP in Wine?