Topic: 3.8 reports, queries and bugs

[Ian @ un4seen]

Here's another try

   www.un4seen.com/stuff/xmplay.exe

[saga]

All seems fine now.

[Folinos]

When i change volume for application in mixer volume windows, change audio volume but not update volume slide in xmPlay.

[Cosworth]

Hi. How should work correctly function "Explore Folder"?
Noticed, first run explore folder, I see opened folder without selected music file. Second run, folder opened with selected music file. Is it bug or it should work that way?

[Ian @ un4seen]

When you click on "Explore Folder", it should open Windows Explorer in the file's folder and select the file. If that isn't happening for you, please state what Windows version you're using.

[Cosworth]

When you click on "Explore Folder", it should open Windows Explorer in the file's folder and select the file. If that isn't happening for you, please state what Windows version you're using.

Win 7 x64

[Ian @ un4seen]

I don't seem to be able to reproduce that here. Does it happen with every file or only the first? Does Windows Explorer take longer to open when the problem happens? If so, perhaps there's some internal timeout that skips the selection step if it takes too long? I'm not sure.

[Cosworth]

I don't seem to be able to reproduce that here. Does it happen with every file or only the first? Does Windows Explorer take longer to open when the problem happens? If so, perhaps there's some internal timeout that skips the selection step if it takes too long? I'm not sure.

Today I've tested this bug, it happens only with Drag'n'Drop folder or Add folder to playlist. I tried on two different PC with Win 7(one x64, second x32). Even with system "Safemod".
It happens with all file numbers.
Windows Explorer run fast without any lags.
I think bug happens only with folder, that you didn't open it after startup PC. But sometime it works correct. It seems like "heisenbug"


Funny thing, I've tried Winamp 5.666 and Explore Folder works very well.

[saga]

XMPlay has an issue with this 15-sample MOD, most samples staying silent. https://modarchive.org/module.php?186114

[Ian @ un4seen]

The problem with that file is that it is shorter than it should be (the final sample is cut short), which is confusing XMPlay's pattern detection (it detects 27 instead of 39) and resulting in it being at the wrong file position for the start of the sample data. There are other 15 sample MOD files that need the pattern detection (to ignore junk in the order list), so it can't be removed but perhaps it an be tweaked. I'll look into it. The tricky thing in this file's case is that there are 27 patterns in the played part of the order list (the higher patterns aren't played) and that number perfectly fits the size of the file (there's space for exactly 27 patterns), so XMPlay's detection looks correct even though it doesn't sound correct.

[garson]

Hi Ian.

Having in mind size differences of various skins, is it possible to add feature that will save position per skin?
For example I have these 2 skins below ,first one has bigger windows so when I change to skin 2, Info window and Playlist window are separated.

Is it possible to save window position per skin (as an option for example)?

[saga]

I think there must some unintentional change with how auto-looping works introduced a while ago, because my loop presets that I set up many moons ago no longer work as intended. For looping MODs, I have set Loop to Never, and "Auto-loop any track ending with sound" is checked and a fade-out duration of 10 seconds is set. Yet, for example the this module just refuses to loop under these conditions: https://modarchive.org/module.php?167095

I also spotted another issue with the sample swapping implementation in ProTracker MODs:
https://modarchive.org/module.php?57492
In the first pattern, channel 4, row 62, you will hear a bogus note. Since there is only an instrument number and no note was previously sounded, it should stay silent.

[Ian @ un4seen]

I think there must some unintentional change with how auto-looping works introduced a while ago, because my loop presets that I set up many moons ago no longer work as intended. For looping MODs, I have set Loop to Never, and "Auto-loop any track ending with sound" is checked and a fade-out duration of 10 seconds is set. Yet, for example the this module just refuses to loop under these conditions: https://modarchive.org/module.php?167095

I think that is related to this loop detection change from earlier this year:

   www.un4seen.com/forum/?topic=15425.msg129368#msg129368

The file's ending sounds like a fade-out already, and the level of the final 10ms isn't high enough to trigger a fade-out by XMPlay.

I also spotted another issue with the sample swapping implementation in ProTracker MODs:
https://modarchive.org/module.php?57492
In the first pattern, channel 4, row 62, you will hear a bogus note. Since there is only an instrument number and no note was previously sounded, it should stay silent.

It seems to be OK when the MOD mode is set to PT1?

[saga]

I think that is related to this loop detection change from earlier this year:

   www.un4seen.com/forum/?topic=15425.msg129368#msg129368

The file's ending sounds like a fade-out already, and the level of the final 10ms isn't high enough to trigger a fade-out by XMPlay.

Maybe the values need to be fine-tuned a bit more? Just looking at the waveform of the last 10ms of that module doesn't really qualify them as "silence", I think. Of course it's quite a balancing act to figure out some good values so maybe a hidden setting would help with finding more suitable values.

It seems to be OK when the MOD mode is set to PT1?

It is, but either way the current behaviour is questionable as it doesn't really reflect anything any ProTracker version (or other tracker) would do. There is no active note and there never has been one on that channel, so a lone instrument number should not start playing a low-pitched noise like it currently does. PT1 mode may be viable for this module to circumvent the issue but it might not be for others.

[saga]

Another issue with sample swapping in normal mode:
https://modarchive.org/module.php?49712
The portamentos on channel 1 used to be played correctly, now the melody gets stuck on the wrong note after changing the instrument. From my understanding the "normal" MOD mode should play as many modules as possible correctly, so maybe the PT1 behaviour in this case could be applied to normal mode as well, until a good argument for not doing so turns up (i.e. lots of songs that somehow depend on the other behaviour, but cannot think of any). And after all, it's more likely that this module was written in PT2 than PT1.

[Ian @ un4seen]

Sorry about the delay.

I think that is related to this loop detection change from earlier this year:

   www.un4seen.com/forum/?topic=15425.msg129368#msg129368

The file's ending sounds like a fade-out already, and the level of the final 10ms isn't high enough to trigger a fade-out by XMPlay.

Maybe the values need to be fine-tuned a bit more? Just looking at the waveform of the last 10ms of that module doesn't really qualify them as "silence", I think. Of course it's quite a balancing act to figure out some good values so maybe a hidden setting would help with finding more suitable values.

Here's an update that should fade-out whenever the MOD loader detects that the file is looped ("looped" is shown beside the length), even if it doesn't meet the non-silent threshold:

   www.un4seen.com/stuff/xmplay.exe

It seems to be OK when the MOD mode is set to PT1?

It is, but either way the current behaviour is questionable as it doesn't really reflect anything any ProTracker version (or other tracker) would do. There is no active note and there never has been one on that channel, so a lone instrument number should not start playing a low-pitched noise like it currently does. PT1 mode may be viable for this module to circumvent the issue but it might not be for others.

Impulse Tracker does play a low-pitched note in this case but I agree that it doesn't really makes sense to do so. The question is why is that line in the MOD file? Anyway, the note shouldn't be played by the update above.

Another issue with sample swapping in normal mode:
https://modarchive.org/module.php?49712
The portamentos on channel 1 used to be played correctly, now the melody gets stuck on the wrong note after changing the instrument. From my understanding the "normal" MOD mode should play as many modules as possible correctly, so maybe the PT1 behaviour in this case could be applied to normal mode as well, until a good argument for not doing so turns up (i.e. lots of songs that somehow depend on the other behaviour, but cannot think of any). And after all, it's more likely that this module was written in PT2 than PT1.

The previous "normal" mode tweak has been tweaked a bit more in the update above. Let me know if there's still a problem with it.

[saga]

Thanks for the update!

Impulse Tracker does play a low-pitched note in this case but I agree that it doesn't really makes sense to do so. The question is why is that line in the MOD file? Anyway, the note shouldn't be played by the update above.

I checked the MOD in Impulse Tracker 2.14 and it didn't play a low-pitched note here; maybe it would do so if there was a note on a previous row. Anyway, from what I can see the MOD file is written this way so that the note on the first row in the following pattern can have both a non-default volume and an offset effect at the same time, something that wouldn't be possible to notate in any other way in a MOD file.

[saga]

Here's another peculiar one

https://modarchive.org/module.php?186761

Disabled and muted channels in S3M files are not supposed to do anything, not even execute global commands (such as tempo / global volume). In this particular file, there are some Wxx commands on a disabled channel which cause the file to fade out prematurely.

Edit: To clarify: Optimally, BASS/XMPlay would ignore global commands on muted channels in S3M files at least optionally (for compatibility with S3Ms made in Impulse Tracker and maybe some other trackers). ST3 and OpenMPT do not handle global commands on muted channels. Disabled channels (i.e. channels that are not assigned to L1...L8 or R1...R8 or any AdLib channels) however should be ignored completely, as I don't think there is any tracker out there that would write such channels, apart from ST3 itself.

[Ian @ un4seen]

Here's an update that will discard S3M channels that are set to 255 (unused):

   www.un4seen.com/stuff/xmplay.exe

Any other channels with bit 8 set will be treated as muted (unless the "Ignore muting in files" option is enabled).

[saga]

Thanks, this sounds better.

[saga]

I have recently observed that priority filetypes for some plugins (in particular xmp-openmpt) get lost so I have to set them up manually again. Has anyone else observed similar issues? Could it be that a plugin update would cause this?

Edit: Someone else has mentioned on support.xmplay.com that the priority filetypes were also reset for them anytime they updated the plugin.

[Ian @ un4seen]

The "priority filetypes" setting is tied to the plugin's filename, so it should persist across upgrades so long as the plugin's filename stays the same. The setting will be lost if XMPlay is run without the plugin loaded, so you shouldn't delete the old plugin and then run XMPlay before installing the new version. Are you seeing the problem happen even if you just copy the new version over the old one?

[saga]

With your explanation, I think I can reconstruct what went wrong. I recently downloaded a new "stuff" build of XMPlay, and I accidentally launched it from Windows' Downloads folder. In that case, no plugins were obviously present and all priority file types were lost, and the settings were lost even after copying xmplay.exe to its intended destination.

It seems like not deleting the priority filetypes would be a safer choice. Sure, it means that some data could clutter up xmplay.ini, but then again it's not a lot of data, and it would only be potentially noticeable if you regularly add and remove new plugins while also editing their priority filetypes.

[Ian @ un4seen]

It isn't currently possible to keep unused "priority filetypes" settings because the settings are read from the "PluginTypes" XMPLAY.INI entry and applied to the appropriate plugins when XMPlay loads. If a plugin is missing then its settings can't be applied/held and are lost once the "PluginTypes" XMPLAY.INI entry is replaced with the current settings when XMPlay closes.

[ramon]

Delix plugin play songs way too fast if output is set to quad channels. No problem if output set to stereo. I have a 5.1 setup and by far prefer my output to quad, but lots of modules can only be played with Delix. Tried with a handful of different formats like .amc, .aon, .aam and same result.

NOTE: All my priorities were erased while I tested without any plugins to isolate the Delix problem by trial and error as I thought it might have been a plugin conflict. When I did put plugins back into XMPlay folder, all my proprieties were lost. ~15 different priories for 20 plugins, lost... and of course, I do not remember which was what after all those years. 


Thanks,
Ramon