Author Topic: Suggestions for 3.9 (Read 226451 times)

piovrauz · « **Reply #25 on:** 1 Jan '14 - 09:14 »

I think they do are .bmp. not "disguised" .png.
Wikipedia has this in the BMP description: "optionally with data compression, alpha channels, and color profiles.".

Muxson · « **Reply #26 on:** 1 Jan '14 - 09:38 »

Yes, but no...
Both as supported: 32bit bmp with .bmp (regular) as well as 32bit png with .bmp modified extension (odd).

See in the skinning kit, xmp-skin.txt:

Quote

All other bitmaps are 24-bit, or 32-bit if they include an alpha channel, BMP files (or PNG renamed to BMP).

I'm arguing on the latter.

piovrauz · « **Reply #27 on:** 1 Jan '14 - 09:43 »

Ah, you mean you'd like .png to be usable without renaming them to .bmp?
Well, it would be more linear, that's true.
Didn't get it earlier, brain still need to tur on for the new year (currently 15%)

Muxson · « **Reply #28 on:** 1 Jan '14 - 18:23 »

Yes, that is it.

But don't worry, no one ever uses 100% of his/her brain power...
Especially not on the 1st of Jan!

AstralSoup Design · « **Reply #29 on:** 2 Jan '14 - 13:54 »

It's time to add Face Scaling to XMPlay, to continue using some old skins on HiDPI displays. It's a feature used by Winamp for long in its Classic Skin.

Knurek · « **Reply #30 on:** 2 Jan '14 - 16:22 »

Song title system overhaul would be lovely, the current %RANDOM_NUMBER format is very limited (not to mention hard to read).

xSF Winamp plugins have a very nice titling scheme, %NAME_OF_TAG%. Way easier to read something like "%title% - %artist% - ©%year%" than "%1%?2{ - %2}%?3{ - %3}%?4{ - ©%4}".

Ian @ un4seen · « **Reply #31 on:** 2 Jan '14 - 16:56 »

Quote from: Muxson on 1 Jan '14 - 00:26

I would like to see png skin elements to be called .png, not disguised as .bmp
It would be much easier to manipulate them to create skins.

Yeah, it would be more convenient if XMPlay looked for files with a ".png" extension in addition to ".bmp", and there isn't really any good reason not to, so here's an update that will do that...

www.un4seen.com/stuff/xmplay.exe

Note that a skin using PNG files will be a bit slower loading than if it was using BMP files, as PNG requires extra processing/decompression. The difference probably won't be very significant/noticeable, still it's probably best to stick with BMP when possible, unless PNG significantly reduces the compiled skin's size (I've not done enough comparisons to say whether it does).

Muxson · « **Reply #32 on:** 3 Jan '14 - 15:04 »

Quote from: Ian @ un4seen on 2 Jan '14 - 16:56

Yeah, it would be more convenient if XMPlay looked for files with a ".png" extension in addition to ".bmp", and there isn't really any good reason not to, so here's an update that will do that...

Thanks Ian, 3.8.0.3 works fine with <png-file>.png!

Quote from: Ian @ un4seen on 2 Jan '14 - 16:56

Note that a skin using PNG files will be a bit slower loading than if it was using BMP files, as PNG requires extra processing/decompression. The difference probably won't be very significant/noticeable...

No, it is not significant/noticeable at all. Especially in regard to the advantage of having transparency support!

Quote from: Ian @ un4seen on 2 Jan '14 - 16:56

... still it's probably best to stick with BMP when possible, unless PNG significantly reduces the compiled skin's size (I've not done enough comparisons to say whether it does).

I don't think it makes any difference in file size (at least for ZIP-compiled skins).
A bmp will be zipped at the ZIP-compilation of the skin where a png is already ZIP-deflated.
Six of one, half a dozen of the other...

Chinese Sausage · « **Reply #33 on:** 27 Jan '14 - 16:29 »

Let's not forget that the actual suggestions are for XMPlay v3.9!

lollollol666 · « **Reply #34 on:** 1 Feb '14 - 22:10 »

Hi i've a small suggestion about 3.9 version. Can you change icon to like this http://www.iconarchive.com/show/mega-pack-2-icons-by-ncrow/XMplay-icon.html or this http://img256.imageshack.us/img256/8882/clipboard1q.jpg (i mean xmp-icon.ico)?.

saga · « **Reply #35 on:** 3 Feb '14 - 21:02 »

This is just a rather small cosmetic thing: In the track info, could the "last played" status maybe not be updated until it has finished playing? When I'm listening to a track at this very moment, I'm not very much interested in finding out that the "last played" date is "just now".

Just to make it completely clear, what I want cannot be achieveed with the "count as played after x seconds" feature, I just want to see the last played date to really be the last played date, and not the current date if I'm playing a track.

saga · « **Reply #36 on:** 4 Mar '14 - 19:27 »

Any thoughts on the previous request?

Jimmy Neutron · « **Reply #37 on:** 5 Mar '14 - 11:03 »

Quote from: saga on 4 Mar '14 - 19:27

Any thoughts on the previous request?

Yeah, I've noticed that "now" isn't very helpful info since you can see and hear that anyway.

"When was the last time?" is a question that crosses my mind when I'm listening to random play in the library, especially if it seems that the track has played recently. A delay in changing the "last played" would help, or maybe not updating it until the next track plays, effectively banishing the "now" tag and making it tagged like the rest of the list shows.

Ian @ un4seen · « **Reply #38 on:** 5 Mar '14 - 17:31 »

I guess it could be useful to know when the current track was previously played, but a nice thing about updating the "last play" value at the start is that it places the current track at the top of the library when it's sorted by "last play" (which is what I usually have myself). Perhaps the library "last play" column could still show "now", while the "Track info" window shows the previous value? Otherwise, I guess an option could be added to delay the "last play" update until after the file has been played/unloaded.

Jimmy Neutron · « **Reply #39 on:** 5 Mar '14 - 23:00 »

Ahhhh..... maybe we are getting too concerned with trying to see where we have been instead of just enjoying the tunes.....

saga · « **Reply #40 on:** 5 Mar '14 - 23:21 »

Quote

Perhaps the library "last play" column could still show "now", while the "Track info" window shows the previous value?

Well, I wouldn't mind that solution, although it might seem a bit inconsistent. Not sure.

zerg · « **Reply #41 on:** 12 Mar '14 - 12:24 »

I'd like more graceful "server full" handling for online streams. Currently, you click the Shoutcast stream, get the server full popup that you have to click, rinse repeat. Kind of like whack-a-mole. Would be nice to forgo the popup and maybe even have a "retry every x seconds until connected" option.

Just my two cents.

Ian @ un4seen · « **Reply #42 on:** 12 Mar '14 - 16:40 »

Quote from: saga on 5 Mar '14 - 23:21

Quote
Perhaps the library "last play" column could still show "now", while the "Track info" window shows the previous value?
Well, I wouldn't mind that solution, although it might seem a bit inconsistent. Not sure.

I'll make the change to the "Track info" window in the next update. To reduce the slight inconsistency, I may have it display both "now" and the previous time.

Quote from: zerg on 12 Mar '14 - 12:24

I'd like more graceful "server full" handling for online streams. Currently, you click the Shoutcast stream, get the server full popup that you have to click, rinse repeat. Kind of like whack-a-mole. Would be nice to forgo the popup and maybe even have a "retry every x seconds until connected" option.

It is possible to disable the "Server full" messages (and other internet error messages) by adding a "NoNetErrors=1" line to your XMPLAY.INI file (under "[XMPlay]").

HellMan666 · « **Reply #43 on:** 13 Mar '14 - 19:15 »

a stunning dark or black, or glossy black or carbon default skin in small/medium/large

WinMEuser · « **Reply #44 on:** 13 Mar '14 - 23:43 »

Just a suggestion, but a "sort by filename" that actually sorts by filename. It shouldn't be called sort by filename when it actually doesn't sort by filename, but rather by path, and disregards whatever song is at the end of the path.

Or at least rename the option "sort by filename" and make it "sort by path." And rename the current option of "sort by title" as "sort by filename."

Dotpitch · « **Reply #45 on:** 14 Mar '14 - 06:30 »

Quote from: WinMEuser on 13 Mar '14 - 23:43

... rename the current option of "sort by title" as "sort by filename."

The title formatting could have a different field order than the filename, so these two are not equivalent in all cases. If it says 'Sort by filename', it should do exactly that, and not use the title formatting at all.

WinMEuser · « **Reply #46 on:** 14 Mar '14 - 10:20 »

well whatever, I won't be bothering with this program anymore. Plenty of better ones out there.

piovrauz · « **Reply #47 on:** 14 Mar '14 - 11:59 »

Awww, makes me think what we really need is a dumb-proof guide for every little XMPlay thing...

saga · « **Reply #48 on:** 14 Mar '14 - 13:21 »

I wonder how many of the "plenty better ones" actually still run on WinME...

piovrauz · « **Reply #49 on:** 14 Mar '14 - 16:14 »

"better ones" is the key work! why did he bother with xmplay if he had already something better?
win me... he really should get another OS, really...