Falcosoft wrote on 2026-03-10, 14:54:

You should consider loops as a continuous way of the playback of the patterns. That is it's the same as if you copied the patterns where the loop starts to the end of the song. So if the pattern where the loop start does not define its own volume level it inherits the volume settings (and of course others as well) from the previous ones. So if no effort is done to prevent differences it's more likely than not that after a loop the patterns will sound differently (volume, pan etc. differences) since the previous patterns before the looped ones differ. You have to make sure that you insert the volume, pan etc. settings to the beginning of the 1st looped pattern to make sure they have the same values as inherited from the previous patterns at 1st playback time without the loop.

I was thinking the same thing, but this bug doesn’t occur when the loop repeats—maybe right at the start, but actually right in the middle of the loop. You can already see it clearly in the waveform: it’s the central portion that’s messed up. The file was generated with OpenMPT. Problems occur with original UMX too.

RetroGC wrote on 2026-03-10, 22:19:

I was thinking the same thing, but this bug doesn’t occur when the loop repeats—maybe right at the start, but actually right in the middle of the loop. You can already see it clearly in the waveform: it’s the central portion that’s messed up. The file was generated with OpenMPT. Problems occur with original UMX too.

I'm not sure that we are talking about the same thing. And I'm also not sure that I'm seeing what you saw 😀
I can only see that the pan/balance of the left/right channels change. At the 1st part the left/right channels are balanced while at the 2nd part the the left channel is quieter while the right channel is louder.
To tell you the truth I do not think I can tell anything more than I have already told above.

But this behaviour should'nt depend on loop. This is deus ex ost if you want to check files (umx or Impulse tracker).
Aldo

RetroGC wrote on 2026-03-10, 23:11:

But this behaviour should'nt depend on loop. This is deus ex ost if you want to check files (umx or Impulse tracker).
Aldo

Hi,
The problem with your mod/loop is exactly what I have written above. But before the detailed explanation let's discuss why your wave record is misleading:
Similarly to Midi in case of mod/it files the context of a command is the 'Channel'. A channel can contain multiple different instruments and the same instrument can be placed on multiple different channels. When you made a per-instrument recording you lost this context so it was a mystery for you how sound changed in the middle of a loop. It's because of this:

That is the 1st part of the record was from different channels than the 2nd part despite the fact that the same instrument can be heard.
Back to the main problem: when you playback your module in OpenMPT you can notice the following Channel Pan value change on Channel 17:

It' because at a later pattern (pattern 7) there is a Channel Pan command that sets the value to 0xAB on Channel 17. So at 1st run the Channel Pan value on Channel 17 is default (0x80) while after the loop it's 0xAB.
The fastest fix is to set the default Channel Pan value explicitly for Channel 17 right at the beginning.

Thank you for your effort. I'm going to check this . I hope this issue is not present in the whole soundtrack (wihch consists in 130 subsong).
[after two hours of stress I've discovered that:] OpenMPT has a feature that solve this issue in general settings (This is an unsuuggested settings btw, but in this case works) and it's: reset channels on loop. [just noted... and almost other 2 hours passed... this is non working on subtrack 3 which usually has an empty pattern]
BTW in deus ex OST i really prefear the output generated but XMPlay as a starting point to import in reaper. So, before works on Reaper what I'm doing is a visual analysis of all independent channel inside reaper, if I'll find a differences... I've to record without loop and loop waves files in reaper (if loop is from ZERO), if loop is not from zero, I'll be forced to use OpenMPT. What a stress!!! Thank you for all your explanations, it was really helpfull.
Aldo

A quick check of 66_test, it will Integer overflow with the attached midi file, while it was ok with 65.

micro wrote on 2026-03-25, 23:47:

A quick check of 66_test, it will Integer overflow with the attached midi file, while it was ok with 65.

Hi,
Thanks for the bug report! It's fixed in latest test version.

BTW, It's a weird Midi file since it contains both GS and MT-32 SysEx messages although the MT-32 messages only disable all parts on an MT-32 so nothing can be heard.
Most likely this file is optimized for a daisy-chained setup with a GS device and an MT-32 and the MT-32 is deliberately disabled to prevent duplicate sound.
In case of such files it seems the better option is to identify them as GS Midi files. This is also implemented in the latest test version:

https://falcosoft.hu/midiplayer_66_test.zip

It works. Thanks!

Hi Zoltan )
I offer you do in your FSMP method reset as I apply in XMPlay , you can seeing as I do reset in XMPlay and this menthod exclude conflicts between MT-32 / GM / GS / XG and SuperMUNT with GM support
I offer add this method and in FSMP so in WinMM MultiPort VSTi )

Roland User wrote on 2026-04-23, 22:04:

Hi Zoltan )
I offer you do in your FSMP method reset as I apply in XMPLay , you can seeing as I do reset in XMPlay and this menthod exclude conflicts between MT-32 / GM / GS / XG and SuperMUNT with GM support
I offer add this method and in FSMP so in WinMM MultiPort VSTi )

You can make any kind of reset sequence for yourself in FSMP:

Yes , but this absent in WinMM MultiPort VSTi , and I think what will better if this option will add ) also as was add option distribution channels per ports

Roland User wrote on 2026-04-23, 22:32:

Yes , but this absent in WinMM MultiPort VSTi , and I think what will better if this option will add )

You can send any kind of resets to the plugin through FSMP or even through XMPlay.

Yes , but this not convenient because if use your WinMM MultiPort VSTi as MIDI Maper for games and do select synthesizer in port for out game music , now need select as reset synthesizer , if was available option reset all synths , so will be better )

Why only this method ?
Because my target do reset each device in native , and for this need do :
1) reset Roland MT-32 to LA / MT-32 standard
2) next need reser all GM devices to GM standard
3) next need reset all GS devices to GS standard
4) next need reset all XG devices to XG standard , but this need result reset only XG devices this way to not reset GS devices to GM standard and not reset MUNT to GM standard , because on this step need reset only XG resert without reset to GM as this maked in XG resets as it was done in the XG reset initially , there firstly send GM reset and next send XG reset , this bad , because all GS devices wiil be in GM mode
5) next reset MUNT to native LA MT-32 dual synth mode