4.0 reports, queries and bugs

[gul]

Hello, I am using version 4.0.0.20.
In Options > Output > File writing, the file selection button (three dots) does not save the selected folder.
In Options > Tools > Tool, the Add button is disabled.
Best regards.   

[Ian @ un4seen]

In Options > Output > File writing, the file selection button (three dots) does not save the selected folder.

Oops! Here's an update to get that working again:

    www.un4seen.com/stuff/xmplay.exe

Regarding adding a tool, if you first enter a name for it then the "Add" button should get enabled.

[gul]

Regarding adding a tool, if you first enter a name for it then the "Add" button should get enabled.

Done 

Oops! Here's an update to get that working again:

It seems to be working as it should.
Thanks

[Faith]

Hello. The "WASAPI plugin rev.4b" seems to have problems with 4.0: it results in a 50% increase in music playback (you can see the track timer speed up too) and a lot of stuttering. This only happens when my output is set to WASAPI. Changing the sample rate doesn't make a difference. I like to use WASAPI because the "Exclusive Mode" means that XMPlay locks the audio signal so that websites cannot interrupt my music. I have disabled WASAPI for the time being to get around this issue, but it would be nice if this could be looked into. I'm on the latest version of Windows 11 (25H2) and XMPlay (4.0.0.1).

[Ian @ un4seen]

I don't seem to be able to reproduce that here. Does changing the buffer length (in the "Output" options page) make any difference? If so, please give a bad setting to check here. Also, is the problem only happening when exclusive mode is enabled (in the "WASAPI" options page) or when it's disabled too?

And did the problem just appear with XMPlay 4.0? If you're unsure, please check with XMPlay 3.8.5, which you can get here:

    https://support.xmplay.com/files_view.php?file_id=685

[Faith]

Hello. Thank you for your quick reply! I tried to move the buffer all the way to the lowest setting, and it seems to have fixed my problem. Very weird. I am not sure if something else updated on my system (like audio driver maybe) during this time, but I never had a problem with the default buffer. I also deleted my settings file before you replied when I was trying to solve this on my own, so I was definitely using the default settings when I was having this problem. I also tested with the old version as you had suggested (3.8.5), and the default buffer length there is also giving me problems now. So I am not yet sure if something changed with Windows or with my audio driver (I updated both Windows and XMPlay at the same time, before this I was using Windows 10).

By the way, small bug I noticed (both on old and new version): the "lock window position" does not lock window size for the extra info window... so I can still resize it. But other than that, everything is working great now. Thank you so much for continuing to support XMPlay after all this time!

[Ian @ un4seen]

I tried to move the buffer all the way to the lowest setting, and it seems to have fixed my problem. Very weird. I am not sure if something else updated on my system (like audio driver maybe) during this time, but I never had a problem with the default buffer. I also deleted my settings file before you replied when I was trying to solve this on my own, so I was definitely using the default settings when I was having this problem. I also tested with the old version as you had suggested (3.8.5), and the default buffer length there is also giving me problems now. So I am not yet sure if something changed with Windows or with my audio driver (I updated both Windows and XMPlay at the same time, before this I was using Windows 10).

To see if it may be something device/driver-specific, do you have another soundcard that you could try for comparison? And does the problem also happen with exclusive mode disabled (in the "WASAPI" options page), or only when it's enabled?

By the way, small bug I noticed (both on old and new version): the "lock window position" does not lock window size for the extra info window... so I can still resize it.

Yeah, the "Lock position" option doesn't currently prevent resizing, eg. the info window's "Auto-resize" option still works.

[yoba]

Hello dear Ian!
Merry Christmas and happy New upcoming Year!
Big thanks for the new version as always!

Few questions about the new Waveform visual plugin.
As it's a "Visualisation", shouldn't it best be placed in the "Vis" sub-folder? I know that plugins and visualiasations can be placed anywhere inside XMPlay's main directory and will work, but just for not to mess different libs and for general order.

Also, shouldn't "[Waveform vis]" section be in the vis.ini and not in the xmplay.ini?

And what is the max supported number of "Samples"?

[Ian @ un4seen]

Hello dear Ian!
Merry Christmas and happy New upcoming Year!

Thanks. Merry Christmas to you too!

Few questions about the new Waveform visual plugin.
As it's a "Visualisation", shouldn't it best be placed in the "Vis" sub-folder? I know that plugins and visualiasations can be placed anywhere inside XMPlay's main directory and will work, but just for not to mess different libs and for general order.

As XMPlay doesn't require any particular folder structure for plugins, I think it's best left to the user to move them if wanted. Having everything in the root of the ZIP file makes it easier to see what's included.

Also, shouldn't "[Waveform vis]" section be in the vis.ini and not in the xmplay.ini?

Only Sonique plugins use the VIS.INI file, with everything else using XMPLAY.INI (except for some Winamp plugins that use their own INI files). I was actually recently thinking of making Sonique plugins use XMPLAY.INI too, but decided to leave it for now, to give more time to consider the pros and cons. Let me know if you see any reason not to do it.

And what is the max supported number of "Samples"?

The valid range is 32-4096. If you enter a number outside of that, you'll see the limited number next time you open the config.

[freakingmayhem]

I noticed a small regression in 4.1: resizing from the top edge of the Extended Playlist seems to have forgotten to actually resize the window.

[Ian @ un4seen]

Oops! I guess you're using Windows 10? I'm seeing the issue there now, while Windows 7 and 11 seem fine. There was a little playlist/library window resizing change in XMPlay 4.1 because the previous method wasn't working properly with Wine/Linux (https://bugs.winehq.org/show_bug.cgi?id=52442). I'll try to find another solution and come back with an update for you to try.

[freakingmayhem]

Yep! Windows 10. (Also, all 3 other edges still work correctly, as you probably noticed.)

[Ian @ un4seen]

Here's an update that detects when it's running in Wine and reverts to the old resizing method if not:

    www.un4seen.com/stuff/xmplay.exe

[freakingmayhem]

Here's an update that detects when it's running in Wine and reverts to the old resizing method if not:

    www.un4seen.com/stuff/xmplay.exe

Nice! It's working for me.

[RedBaron]

I have come back to this website after a long time to find out that there is a v4.1
I was using 3.8

I generally keep XM Play in mini mode hovering in the taskbar.
I see a bug in v4.1 in which I cannot completely drag XM Play to the bottom where the taskbar is. It gets stuck midway.

I am using the WMP11 skin in mini mode on Win 11 Home

[RedBaron]

Sorry to post again but the link to the picture was excluded.



https://freeimage.host/i/fLbPndG

[Han Solo]

Ok, so here we go with a test...



It says first, xmplay 4.1 is running mostly fine on a win 10 machine
And second, that the Metrocity skin, precisely the spectrum visualizer,
uses measurable cpu loads (30-40% cpu load) compared to the default
"rainbowy" spectrum visualizer (some 5-10% cpu load)...

Hmm, just realized I could post it to some skin-oriented thread, but
I'll leave it here as my "hello" post.

[Ian @ un4seen]

I generally keep XM Play in mini mode hovering in the taskbar.
I see a bug in v4.1 in which I cannot completely drag XM Play to the bottom where the taskbar is. It gets stuck midway.

I am using the WMP11 skin in mini mode on Win 11 Home

XMPlay 4 prevents itself being moved totally outside of Windows' "work area" (which excludes the taskbar), so that it doesn't get lost. It always keeps at least 10 pixels visible.

When you previously put XMPlay entirely within the taskbar area, wouldn't it disappear (under the taskbar) whenever you clicked on the taskbar?

It says first, xmplay 4.1 is running mostly fine on a win 10 machine
And second, that the Metrocity skin, precisely the spectrum visualizer,
uses measurable cpu loads (30-40% cpu load) compared to the default
"rainbowy" spectrum visualizer (some 5-10% cpu load)...

I'm not seeing such high CPU usage here, but perhaps it's related to the fact that the skin's spectrum display and position indicator/slider are interlaced. That requires complex clip regions, which I guess might be slow with some video cards/drivers. What video card are you using and do you have the latest drivers installed?

For comparison, what CPU usage do you see with the "Escape [Default]" skin? That has a similar spectrum display but it isn't interlaced.

[RedBaron]

I generally keep XM Play in mini mode hovering in the taskbar.
I see a bug in v4.1 in which I cannot completely drag XM Play to the bottom where the taskbar is. It gets stuck midway.

I am using the WMP11 skin in mini mode on Win 11 Home

XMPlay 4 prevents itself being moved totally outside of Windows' "work area" (which excludes the taskbar), so that it doesn't get lost. It always keeps at least 10 pixels visible.

When you previously put XMPlay entirely within the taskbar area, wouldn't it disappear (under the taskbar) whenever you clicked on the taskbar?

I get your point. I need to click on XM Play in the taskbar to see it again.
But now I have to keep the player behind other apps like the browser and see the same behavior.

Is there an 'Always on Top' option?

[Ian @ un4seen]

Yes, there's an "On top" option in the "Interface" options page, to set whether XMPlay should stay on top of other windows in normal and/or mini modes. It's enabled by default in mini mode.

[Han Solo]

And second, that the Metrocity skin, precisely the spectrum visualizer,
uses measurable cpu loads (30-40% cpu load) compared to the default
"rainbowy" spectrum visualizer (some 5-10% cpu load)...

For comparison, what CPU usage do you see with the "Escape [Default]" skin? That has a similar spectrum display but it isn't interlaced.

I've measured some totals now (because the cpu load is divided between
xmplay and window manager) when left alone, no mouse moving etc..



So, well, the spectrum from "Escape" does yield a lesser load...
But hey, nothing hangs or whatever, so it's not such a big deal.
The notebook is a cheap-o-tronic with intel uhd 600 onboard.

[yw4z]

hi Ian, currently updated 4.0.0 to 4.1.0.3

have found my custom made skin not working properly even when png image has 100% opacity but works when it has 99% opacity.
problematic ones; info_right.png, info_bottomleft.png, info_bottomright.png, info_left.png, info_bottom.png
im saving images with photoshop. added related files with examples

also i have noticed one missing feature, previous button can play song from beginning after x time passed. i find myself regularly using previous then next button when i want to listen track from start

thanks. its working great as always

[Ian @ un4seen]

To make it easier to see what's going wrong, please provide the entire skin. If you would like to keep it private, you can upload it here (or email it):

    ftp://ftp.un4seen.com/incoming/

[yw4z]

sent mail to support now