Suggestions for 3.9

[Ian @ un4seen]

I'm using an ultra high resolution monitor and the default skin is nearly unreadable, but the 'hours' is shown - the skin I'm using I got from someone on another forum and it appears that when the "font_listsize" and "font_listnumsize" is set above about 48-52 points it cuts the 'hours' off. When I drag and drop a track that's over an hour into the playlist it cuts off the 'hours'  and that's true whether for not the 'type' column is active or not. But, switching skins back and forth or restarting xmplay it displays correctly.Also this is with the playlist panel and not when the playlist is incorporated into the main panel- I hope that makes sense.

Please upload that skin to have a look at here:

   ftp.un4seen.com/incoming/

Can the 'Total time/count display' be given it's own setting in 'skinconfig.txt' maybe a new parameter 'font_listtimesize' can be created so that the size can be set independently - right now it uses the 'font_listnumsize' which is also used as the playlist track number/time.

Yes, I think that can be arranged.

I haven't noticed that before, but apparently there's a need for correction on how XMPlay's maximum text width works:



Here, I set it to 24 characters and used absurdly long path with a long album title. As can be seen the text is broken between letter characters but as Japanese language doesn't use spaces the line is not broken as supposed. Or maybe that's because of squareness of the characters.

P.S. In case you wonder, Japanese sentence can be split mid-word, that's normal.

XMPlay currently splits lines at spaces. I suppose XMPlay would need to detect when Japanese characters are used, and perhaps others too? Do you know what Unicode blocks it should look for?

P.P.S. Apparently there's an issue with splitting file path when XMPlay is running under Japanese system and ¥ character is used instead of \

Can either character be used, ie. could XMPlay simply replace all '¥' in filenames with '\'? For reference, please upload your XMPLAY.PLS file to have a look at here:

   ftp.un4seen.com/incoming/

[mortstev]

Please upload that skin to have a look at here:
   ftp.un4seen.com/incoming/

It's there - at least I hope it is, when I do an 'ls -l' it doesn't appear in the listing, but I uploaded it and did get "Transfer complete".

The file names are:
albumart.xmpskin
and
albumart-bigger.xmpskin

You can also make those available in the 'skins' section for everyone to download if you'd like.

Thanks for you help!

Mort
--

[tails__]

Can either character be used, ie. could XMPlay simply replace all '¥' in filenames with '\'? For reference, please upload your XMPLAY.PLS file to have a look at here:

I've uploaded the playlist to FTP. As far as I can see, it's just the font having backslash symbol replaced with half-width yen character for compatibility reasons.

Now, about unicode blocks. Main CJK stuff can be found in this range:



And second Chinese block is there:



Then, there is U+FF00–FFEF range which defines full-width ASCII variant with half-width katakana (second Japanese syllabary) which begins at U+FF66 and ends at U+FF9F:



Characters U+FF9E and U+FF9F have to be stacked together with character they came after though.

[Ian @ un4seen]

It's there - at least I hope it is, when I do an 'ls -l' it doesn't appear in the listing, but I uploaded it and did get "Transfer complete".

The file names are:
albumart.xmpskin
and
albumart-bigger.xmpskin

The skins were received, thanks. I don't seem to be able to reproduce the problem though. Do I need to make some changes to the skin's skinconfig.txt file? If so, please give those too.

I've uploaded the playlist to FTP. As far as I can see, it's just the font having backslash symbol replaced with half-width yen character for compatibility reasons.

Oh, is it just the font that is making the backslashes look like something else? If so, I'm not sure what can be done about that. Do you see it happen with all fonts? If so, I guess it affects other software too?

Now, about unicode blocks. Main CJK stuff can be found in this range:



And second Chinese block is there:



Then, there is U+FF00–FFEF range which defines full-width ASCII variant with half-width katakana (second Japanese syllabary) which begins at U+FF66 and ends at U+FF9F:



Characters U+FF9E and U+FF9F have to be stacked together with character they came after though.

Does that mean everything between 3190-A48F and 20000-2FA1F can be split anywhere?

[tails__]

Oh, is it just the font that is making the backslashes look like something else? If so, I'm not sure what can be done about that. Do you see it happen with all fonts? If so, I guess it affects other software too?

Yes, actually, with Korean fonts backslash is replaced with something like W, so this is just font issue. Still, cutting text at "\" character code would be nice.

Does that mean everything between 3190-A48F and 20000-2FA1F can be split anywhere?

It is, yes.

[mortstev]

The skins were received, thanks. I don't seem to be able to reproduce the problem though. Do I need to make some changes to the skin's skinconfig.txt file? If so, please give those too.

No. No changes to the  skinconfig.txt file are needed.

Maybe a little better description of the problem will help...
The hour seems to get cut off if you drag and drop into the player. Also it appears more often if there is only one sound file over an hour in length being dragged and dropped, but not always, sometimes if you drag and drop a bunch of short files (~4-5 minutes each maybe 6 of them) and with a couple of long (over an hour) length files it cuts the hour number off. If there are already entries in the playlist over an hour and you drag another entry over an hour in length into the playlist it resizes that column to accommodate the 'hour' - I hope that makes sense, if you need anything more let me know.

Also unrelated, but can an option to display the MP3 Tag Version (ie. ID3v2, ID3v1, APEv2, etc.) be added to the Info display-maybe as part of 'skinconfig.txt' in the form of 'pos_infoIDver' to display or hide the ID Version.

Thanks for your help.

Mort

[mortstev]

Okay here's how I've been able to consistently reproduce the problem with the 'hours' column...

I've uploaded to the ftp site a file with the mp3 files I've noticed the problem it's called "hourproblem.zip" I also re-uploaded a files called "aaskins.zip" to be sure you have the exact same skin files as I do and included in there is my "xmplay.ini" (in case there's something in there that's unique to my system, one last thing I'm using XMPlay version 3.8.2.30.

Start by opening XMPlay and setting the 'album-art' skin, open the playlist (if not already opened) then closing XMPlay then:

1) open xmplay, open the playlist (should already be opened), right click on the "X" (next to 'random' on the righthand side of the playlist panel) and select 'remove all', exit xmplay

2) start xmplay, select all the files in the 'hourproblem' folder, drag them into xmplay and release them over the 'loading....' position bar (I don't know if this really makes any difference).

The image file "hourcolproblem.gif" shows the results with the hours column missing.

I hope this helps... doing it this way I've been able to reproduce the cut off 'hours' column 100% of the time. Also, if you remove the files from the list and then drop the files back into the player without exiting and restarting the player it loads the 'hour' column correctly - I believe this problem is somehow related to the mp3 files being cached and how long it takes to read the MP3 ID Tags and determine the length of the file. Also the problem is reproducible by dragging the 'zip' file into the xmplayer instead of the uncompressed files. One final thing I first noticed this loading sound files from a USB stick, but I've since done it from hardrives, SSD as well as RAM drives and as long as the files aren't cached I've been able to reliably reproduce it.

FWIW... I have the parameter "PlayDelay=3" set in the 'xmplay.ini' file, but in changing it to different values it doesn't appear to have any effect on the problem.

Also... there seems to be a problem with the way CUE files are handled. In that directory is a cue file named "03. Cue_File.cue" if you drag it into the player nothing happens, but if you rename it to "03. Apollo-13-Problem.cue" and then drag it in the player it works fine... somehow the 'FILE' portion in the cue file is  being ignored and for some reason the name of the cue file has to match the name of the MP3 file. Cue files are just plain ASCII text and can be opened with with Window's notepad and you'll see the 'FILE' name set correctly. I probably didn't do a very good job explaining the problem, but if you drag the cue file into the player then rename it and do the same thing I think you'll see what I'm talking about.

Another suggestion... sorry I'm being a pest! But, can the playlist panel be made to 'snap' against the edges of the XMplayer? Makes positioning it with the player a whole lot easier.

Thanks, again for putting up with me!

Mort
--

[Ian @ un4seen]

I haven't noticed that before, but apparently there's a need for correction on how XMPlay's maximum text width works:



Here, I set it to 24 characters and used absurdly long path with a long album title. As can be seen the text is broken between letter characters but as Japanese language doesn't use spaces the line is not broken as supposed. Or maybe that's because of squareness of the characters.

Here's an update for you to try...

   www.un4seen.com/stuff/xmplay.exe

If there are no spaces before the max width is reached, then it will just break the text mid-word rather than breaking at the next space.

Okay here's how I've been able to consistently reproduce the problem with the 'hours' column...

I've uploaded to the ftp site a file with the mp3 files I've noticed the problem it's called "hourproblem.zip" I also re-uploaded a files called "aaskins.zip" to be sure you have the exact same skin files as I do and included in there is my "xmplay.ini" (in case there's something in there that's unique to my system, one last thing I'm using XMPlay version 3.8.2.30.

Start by opening XMPlay and setting the 'album-art' skin, open the playlist (if not already opened) then closing XMPlay then:

1) open xmplay, open the playlist (should already be opened), right click on the "X" (next to 'random' on the righthand side of the playlist panel) and select 'remove all', exit xmplay

2) start xmplay, select all the files in the 'hourproblem' folder, drag them into xmplay and release them over the 'loading....' position bar (I don't know if this really makes any difference).

The image file "hourcolproblem.gif" shows the results with the hours column missing.

Oh yes, I can reproduce that. The update above should fix it. Let me know if you still see it happen.

[mortstev]

Oh yes, I can reproduce that. The update above should fix it. Let me know if you still see it happen.

seems to have fixed it -- thanks

[augitesoul]

Would Discord integration be possible? It could show the music you play currently in the "Playing:" textfield.

[Ian @ un4seen]

I'm not familiar with how Discord works, but perhaps it would be possible to adapt the old MSN "now playing" plugin for it? That plugin works by finding the MSN window and sending a WM_COPYDATA message (containing the title) to it. The source code is included in the XMPlay plugin SDK, which is available from the XMPlay page.

Alternatively, if Discord needs to pull the title from XMPlay, that is available via DDE: service = "XMPlay", topic = "info0" (for the General info window text).

[augitesoul]

I will look into the plugin, to adapt it, thanks

[saga]

It appears that for WAV files, XMPlay attempts to decode metadata as UTF-8 and if that fails, it falls back to ANSI. It is apparently very little known that there is actually a RIFF chunk for setting the character set for strings! It's the "CSET" chunk, it exists since the very early RIFF days and the first two bytes of that chunk indicate the Windows codepage (which can also be UTF-8, CP 65001). Maybe XMPlay should first try to read the metadata according to the CSET chunk before falling back to heuristics.
I've attached two example files, both have a CSET chunk that indicates an UTF-8 codepage, but one of them contains a malformed UTF-8 string. Still, both should be decoded as UTF-8.

[cong]

Better file type names rather than have everything called "XMPlay-able file".

and maybe more icon choices for each type of file. Currently it let's us choose one icon for all supported files. One icon design is great but I like my playlists and songs to have a different icon.

Also windows doesn't let me associate files with xmplay. I think that's broken in windows 10.

[saga]

Using the most recent XMPlay version, file types should actually no longer show up as "XMPlay-able file" but rather "MP3 file" or similar. There are some icon packs for various formats available on the forum, but you have to assign them manually. You should be able to find them by doing a forum search.

[cong]

I made my own icon because I didn't like the xmplay one. Nothing fancy, something to fit in with the rest. I'm using the most recent, 3.8.2.3.

[Ian @ un4seen]

It appears that for WAV files, XMPlay attempts to decode metadata as UTF-8 and if that fails, it falls back to ANSI. It is apparently very little known that there is actually a RIFF chunk for setting the character set for strings! It's the "CSET" chunk, it exists since the very early RIFF days and the first two bytes of that chunk indicate the Windows codepage (which can also be UTF-8, CP 65001). Maybe XMPlay should first try to read the metadata according to the CSET chunk before falling back to heuristics.
I've attached two example files, both have a CSET chunk that indicates an UTF-8 codepage, but one of them contains a malformed UTF-8 string. Still, both should be decoded as UTF-8.

Interesting. I'll look into that, thanks.

I made my own icon because I didn't like the xmplay one. Nothing fancy, something to fit in with the rest. I'm using the most recent, 3.8.2.3.

3.8.2.3 is the current release version, but the latest "in development" XMPlay build (that saga is referring to) is available here:

   www.un4seen.com/stuff/xmplay.exe

[obertres]

I would like the function to modify the name and size of the typeface of the playlist. I'm short of sight. Thank you.

[Azevedo]

I really would like to see the options window re-organized in a future version. The layout is all clumsy and too tight.

Make the text size a little larger and spaced

I guess it was designed thinking of the 640x480 screen user. Nobody uses 640x480 anymore.

[Zzyzx]

Is there a way, or would it be easy to add, some sort of "track" or item that could be inserted into the playlist panel that would cause the player to pause (literally like pressing the pause button)?

Use case: I'm listening to an album (set of tracks). I have several albums queued up for listening in sequence. When the current album is over I want to stop and go do a couple of things, then come back and continue. Currently, I queue up a 10 second track of silence in between the albums to get my attention so I can hit pause, but it would be nice to just insert a pause "track" in there. Make sense?

Cheers,
Paul

[Zzyzx]

Is there a way, or would it be easy to add, some sort of "track" or item that could be inserted into the playlist panel that would cause the player to pause (literally like pressing the pause button)?

Use case: I'm listening to an album (set of tracks). I have several albums queued up for listening in sequence. When the current album is over I want to stop and go do a couple of things, then come back and continue. Currently, I queue up a 10 second track of silence in between the albums to get my attention so I can hit pause, but it would be nice to just insert a pause "track" in there. Make sense?

I notice there is a "Stop at dead track" option on the Looping button right click menu.

Am I correct that if I inserted a "dead track" where I wanted it to pause, it would stop there, and I could double-click the first track of the next album when I wanted it to resume?

If the above is correct, what would be an example of a good "dead track" to insert?

When it stops at the dead track, would it clean up the dead track (remove it from the queue and playlist panel)?

Thanks!

[saga]

Maybe "stop at end of queue" would suit your use case?

If the above is correct, what would be an example of a good "dead track" to insert?

Any file that doesn't exist or is not a music file. Or, you could generate a really long audio file consisting only of silence, and then e.g. compress it using FLAC to reduce its size to next to nothing. This could then serve as a gap track.

[Zzyzx]

Maybe "stop at end of queue" would suit your use case?

If the above is correct, what would be an example of a good "dead track" to insert?

Any file that doesn't exist or is not a music file. Or, you could generate a really long audio file consisting only of silence, and then e.g. compress it using FLAC to reduce its size to next to nothing. This could then serve as a gap track.

Thanks for the reply!

"Stop at end of queue" isn't what I want, since I want to queue up multiple albums at a time, and pause in between them.

I currently use a silence track in between, but that doesn't pause on its own. I have to recognize the silence, reach up and hit pause. Sure, if I made it about 12 hours long, I could just let it play and hit track advance when I get back...

I'll have to see how a dead track works out.

As a feature suggestion, perhaps the ability to insert "control" tracks into a playlist/queue would be interesting.

[sveakul]

1.  Ability to save/load custom settings for the built-in
equalizer.

2.  Native VST host (one can hope!  )

[saga]

You can already save and load presets for EQ and other DSPs, see attached image. Double-click a saved setting from the list to load it.