What can i do to help you further? What information do you need?

EDIT:

If its scummvm specific things:
Im playing monkey island 1 and 2.
In the game specific settings:
-Audio tab: Overwrite global settings (checked) - Musicdevice = Midi Through [ALSA]
-Midi tab: Overwrite global settings (checked) - GM-Device = NONE - mixed adlib/midi mode (checked)
-MT32 tab: Override global settings (checked) - MT32-device = Midi Through [ALSA]

DOSShark wrote on 2026-10-30, 18:21:

What can i do to help you further? What information do you need?

How can I reproduce your error simply using Wine + ScummVM on my Linux Mint without all the other stuff you mentioned?
BTW, I do not think that I can do anything anyway since most likely the problem is not with Munt VSTi but with some of the Linux component(s) you use. The hard thing is to identify which one.

Ok.
(1) Use ScummVM.
(2) Monkey Island 1 and 2.
(3) Set game specific settings in the way i mentioned in my last edited post above.
(4) In your player set midi through port as input
(5) Use your munt vsti Instrument with default settings.
(6) Play the game(s).
(7) On Monkey 1 the intro music is already broken for me.

DOSShark wrote on 2026-10-30, 18:35:

Ok. (1) Use ScummVM. (2) Monkey Island 1 and 2. (3) Set game specific settings in the way i mentioned in my last edited post abo […]
Show full quote

Ok.
(1) Use ScummVM.
(2) Monkey Island 1 and 2.
(3) Set game specific settings in the way i mentioned in my last edited post above.
(4) In your player set midi through port as input
(5) Use your munt vsti Instrument with default settings.
(6) Play the game(s).
(7) On Monkey 1 the intro music is already broken for me.

Some things should be tried by you first:
1. Play the Monkey Ireland MT-32 Midi file with FSMP first and Munt VSTi loaded. Listen if you can experience the same problem.
2. Eliminate ScummVM from the equation. That is play the Monkey Ireland MT-32 Midi file with another Linux Midi Player through the same port you use with ScummVM so that FSMP + Munt VSTi loaded produce the sound.
Listen if you can experience the same problem.

Here are the MT-32 versions:

I dont have a midi file- the music comes directly from the game.
But i tested dosbox and the game doom with your munt plugin and it works perfect - so its a scumm vm thing.
And this is probably out of your hands.

Thanks a lot for taking your time to help me 😀.

EDIT:
Oh - i didnt see you provided 2 midi files.
I only tested Monkey Island 1 midi and like the doom music data from dosbox this works.

DOSShark wrote on 2026-10-30, 18:55:

I dont have a midi file- the music comes directly from the game. But i tested dosbox and the game doom with your munt plugin and […]
Show full quote

I dont have a midi file- the music comes directly from the game.
But i tested dosbox and the game doom with your munt plugin and it works perfect - so its a scumm vm thing.
And this is probably out of your hands.

Thanks a lot for taking your time to help me 😀.

EDIT:
Oh - i didnt see you provided 2 midi files.
I only tested Monkey Island 1 midi and like the doom music data from dosbox this works.

Have you also tried point 2. that is not using FSMP for playback but using another Linux based Midi player through the same port as used by ScummVM?
You should also attach a rendered part of the badly sounding ScummVM version as wav/mp3 so that I can have a clue about what you actually hear.
And a screenshot of the Munt VSTi plugin when the bad sound happened ( and a description about at what part it happened).

DOSShark wrote on 2026-10-30, 13:35:

Thanks for replying so fast :) Im using garuda linux with cachyos packages + bore kernel 7.2.11. To launch your player im using […]
Show full quote

Thanks for replying so fast 😀
Im using garuda linux with cachyos packages + bore kernel 7.2.11.
To launch your player im using bottles with GE Proton 11-9.
System uses pipewire but the midi port im using is 14:0 - midi through port (i thinks its the kernel one) and this one is available as input to your player.
Normal GM midi from dosbox games (Doom, Descent etc.) works great. Even managed the linux openttd to send midi data through aplaymidi to your player - all working flawless.
Its specific to Munt plugin and scummvm linux version.

As variant , you can try use my solution MIDI Router, here very powerful filtration sysex messages , especially for MUNT from FalcoSoft ) , may be this can help you solve your problem and you can use my solution and solution from FalcoSoft )

Hello, I've been finding FSMP very useful.

I'd like to report a problem that has been bothering me for a long time.
I'm using Windows 10 with the taskbar set to appear at the top of the screen.
Every time I restart FSMP, the MIDI Text (lyrics) display shifts to the top of the screen.
This means that the adjusted display position is not fixed.
Other elements besides the MIDI text (lyrics), such as visualizations, are fixed.

I understand that the vast majority of people use the taskbar at the default bottom position, and only a small minority use it at the top.
This is probably a problem that wouldn't be noticed without someone reporting it.
I would appreciate it if you could fix the issue so that the position remains fixed even after restarting.

I appreciate the maintenance and improvements to FSMP.

Tetrapod wrote on 2026-11-01, 07:31:

Hello, I've been finding FSMP very useful. […]
Show full quote

Hello, I've been finding FSMP very useful.

I'd like to report a problem that has been bothering me for a long time.
I'm using Windows 10 with the taskbar set to appear at the top of the screen.
Every time I restart FSMP, the MIDI Text (lyrics) display shifts to the top of the screen.
This means that the adjusted display position is not fixed.
Other elements besides the MIDI text (lyrics), such as visualizations, are fixed.

I understand that the vast majority of people use the taskbar at the default bottom position, and only a small minority use it at the top.
This is probably a problem that wouldn't be noticed without someone reporting it.
I would appreciate it if you could fix the issue so that the position remains fixed even after restarting.

I appreciate the maintenance and improvements to FSMP.

Hi,
Unfortunately I could not reproduce your problem. I also use Windows 10 and the MIDI text (lyrics) dialog is opened exactly at the place it was at the last time regardless of the Windows taskbar position.
So something else is missing that results in this strange phenomenon. Here is my test video:
https://youtu.be/O81Y4jOZH20

Thank you for your quick reply.

Is this a problem that only occurs in my environment? I really didn't expect it to be so difficult to reproduce.
I was quite certain that the misalignment was caused by the taskbar's position, so this is disappointing.

I've prepared a video to show you, as evidence, how it shifts.

top
https://drive.google.com/file/d/17fGKelFJhU6_ … kSIcmBHl8QgQPe/
bottom
https://drive.google.com/file/d/1Y3wFFG-XaHU5 … 87RisO_gk2LcJh/

Tetrapod wrote on 2026-11-01, 09:04:

Thank you for your quick reply. […]
Show full quote

Thank you for your quick reply.

Is this a problem that only occurs in my environment? I really didn't expect it to be so difficult to reproduce.
I was quite certain that the misalignment was caused by the taskbar's position, so this is disappointing.

I've prepared a video to show you, as evidence, how it shifts.

top
https://drive.google.com/file/d/17fGKelFJhU6_ … kSIcmBHl8QgQPe/
bottom
https://drive.google.com/file/d/1Y3wFFG-XaHU5 … 87RisO_gk2LcJh/

If I were you I would try to change the position of the Text/Lyrics Window in different ways to determine what conditions are necessary to trigger the problem.
E.g.
1. Is the problem also triggered if the Text/Lyrics dialog is the only opened Dialog?
2. What happens if you move the Text/Lyrics dialog to the other side of the Player without other dialogs surrounding it?

I've been dealing with this positional shift problem for a long time, so I think I've done a lot of testing with different conditions.
That's why I wrote in my previous post that I was convinced the problem was the taskbar's position.

The same result is obtained under all the different conditions I tried. (I didn't measure the exact number of pixels, but it shifts upwards by about the same width as the taskbar height.)

1. It will be misaligned.
2. Player + Lyrics Dialog Only: Under the condition that no VSTs or other dialogs are present, the dialog's position will shift after restarting from its final position when the player was last closed, regardless of its current position, size, aspect ratio, or distance.

The only time it doesn't shift is when the taskbar is at the bottom.
The issue can be reliably reproduced by restarting FSMP when the taskbar is positioned at the top.

I noticed something after rewatching Falcosoft's test video.
The issue of the lyrics dialog shifting upwards might be reproducible if you disable the automatic hiding function for the taskbar and display it at the top of the screen.

My guess is that the phenomenon of the screen shifting slightly upwards each time it restarts is because, if there is a taskbar at the top that is always displayed, the reference point is the area remaining after subtracting the height of the taskbar from the total screen area.

I realized that even if the taskbar is actually located at the top of the screen, if the setting is to automatically hide the taskbar, it might not be considered as being at the top of the screen when you press the close button.

Tetrapod wrote on 2026-11-01, 14:02:

I noticed something after rewatching Falcosoft's test video.
The issue of the lyrics dialog shifting upwards might be reproducible if you disable the automatic hiding function ...

Yes, that was the missing piece. Here is an update that fixes this problem:
https://falcosoft.hu/midiplayer_67_test.zip

This variant I can not download
The page you have requested cannot be found on this server.

Requested URL: falcosoft.hu/midiplayer_67_test.zip
Redirect status: 404
You can try the home page of the site to find what you're looking for:

Falcosoft home page

------------------------------------------------------------------------------------------------
A keresett oldal nem található a szerveren.

Keresett URL: falcosoft.hu/midiplayer_67_test.zip
Átirányítás állapota: 404
Megpróbálhatja megtalálni a keresett oldalt a kezdőlap segítségével:

Falcosoft kezdőlap
but site https://falcosoft.hu/index.html work corerectly )

Roland User wrote on 2026-11-01, 19:28:

This variant I can not download The page you have requested cannot be found on this server. […]
Show full quote

This variant I can not download
The page you have requested cannot be found on this server.

Requested URL: falcosoft.hu/midiplayer_67_test.zip
Redirect status: 404
You can try the home page of the site to find what you're looking for:

Falcosoft home page

------------------------------------------------------------------------------------------------
A keresett oldal nem található a szerveren.

Keresett URL: falcosoft.hu/midiplayer_67_test.zip
Átirányítás állapota: 404
Megpróbálhatja megtalálni a keresett oldalt a kezdőlap segítségével:

Falcosoft kezdőlap
but site https://falcosoft.hu/index.html work corerectly )

Try the download link again. It was most likely a Cloudflare caching issue.

Thank you ) now all downloaded )

I've become very interested in the recent advancements in SXG-Create-NF Patcher, which has led me to restart FSMP so frequently that I registered a VOGONS account to report my issues.
I have confirmed that the issue has been fixed. Thank you for addressing my minor but troublesome problem.

This is a different topic.

I encountered a strange behavior while trying to play music data using ports 1-4 with FSMP, so I'd like to explain it.

1. Start FSMP. The S-YXG xx VSTi is loaded.
2. Click on the port selection area on the VSTi; naturally, the port will not change.
3. Play one of the following tracks: XG (32Ch) / GS (32Ch) / SC-88 (32Ch).
4. Click on the port during playback; the port will switch correctly.
[A>B->A>B>] C and D are not selected. This is the expected behavior.
5. Stop playback.
6. Clicking a port before playing the next song will put you in a state where you can switch between any of the 4 ports [A>B>C>D->A>].
7. After step 6, you will be able to switch between A, B, C, and D regardless of whether you are playing a song that uses only one port or a song that uses all four ports.
8. I wondered if the actions from step 6 to step 7 were the intended behavior, as it did not revert to the initial FSMP startup state.
9. Incidentally, when you select and play a song from XG (48Ch) during the initial startup, if you switch by clicking, [A>B>C->A>] D will not be selected.
I think that's the correct behavior.
10. The actions after stopping playback will be the same as those described in section 6 and onward.

I apologize for the confusing explanation, but I'll summarize what I wanted to say.

Once you play a song using multiple ports, the port selection after playback will always be [A>B>C>D->A>] and will not revert to the initial startup state.
It seems natural that after pressing the stop button, it should return to the initial startup state (immediately after the VSTi was first loaded).

(I don't know if this is due to NightFright's reasons or FSMP's circumstances.)

Currently, it's not a major problem, and I'd accept it if they said it was by design, but I wanted to confirm whether it was an intentional behavior.

Tetrapod wrote on 2026-11-02, 01:35:

I've become very interested in the recent advancements in SXG-Create-NF Patcher, which has led me to restart FSMP so frequently […]
Show full quote

I've become very interested in the recent advancements in SXG-Create-NF Patcher, which has led me to restart FSMP so frequently that I registered a VOGONS account to report my issues.
I have confirmed that the issue has been fixed. Thank you for addressing my minor but troublesome problem.

This is a different topic.

I encountered a strange behavior while trying to play music data using ports 1-4 with FSMP, so I'd like to explain it.

1. Start FSMP. The S-YXG xx VSTi is loaded.
2. Click on the port selection area on the VSTi; naturally, the port will not change.
3. Play one of the following tracks: XG (32Ch) / GS (32Ch) / SC-88 (32Ch).
4. Click on the port during playback; the port will switch correctly.
[A>B->A>B>] C and D are not selected. This is the expected behavior.
5. Stop playback.
6. Clicking a port before playing the next song will put you in a state where you can switch between any of the 4 ports [A>B>C>D->A>].
7. After step 6, you will be able to switch between A, B, C, and D regardless of whether you are playing a song that uses only one port or a song that uses all four ports.
8. I wondered if the actions from step 6 to step 7 were the intended behavior, as it did not revert to the initial FSMP startup state.
9. Incidentally, when you select and play a song from XG (48Ch) during the initial startup, if you switch by clicking, [A>B>C->A>] D will not be selected.
I think that's the correct behavior.
10. The actions after stopping playback will be the same as those described in section 6 and onward.

I apologize for the confusing explanation, but I'll summarize what I wanted to say.

Once you play a song using multiple ports, the port selection after playback will always be [A>B>C>D->A>] and will not revert to the initial startup state.
It seems natural that after pressing the stop button, it should return to the initial startup state (immediately after the VSTi was first loaded).

(I don't know if this is due to NightFright's reasons or FSMP's circumstances.)

Currently, it's not a major problem, and I'd accept it if they said it was by design, but I wanted to confirm whether it was an intentional behavior.

1.The part that once a port is activated it will never be disabled again seems to be intentional in case of S-YXGMxx plugins:
https://github.com/NightFright2k19/SXG-Create-NF/pull/80

2. FSMP supports 4 ports so when it stops a multi port Midi file it sends All Sounds off and All Notes off messages to all 4 ports. This is also intentional. This is because even in case of a 32-channel Midi file FSMP does not know actually which ports received Midi messages ( 1 and 2, 1 and 3, 2 and 3, 3 or 4 etc). So to prevent hanging notes it sends these messages to all ports.
To be more clear: FSMP can support even such multi-port Midi files that use e.g ports 37 and 39, 81, 95 ( yes, there are such files). But translates them in real time to be always in the port 1-4 range.

Thank you for providing such a detailed explanation of my question.
I see, after reading the explanation, I understand what's happening internally.
It seemed like strange behavior to me, but it was due to my lack of understanding. Sorry.