Suggestions for 3.9

Started by AstralSoup Design,

Reply Print
Go Down Pages 1 2 3 4 ... 25

nothingness

#20
Last Edit: by nothingness
I agree, it'd be nice to have access to the most common secret settings in the app.

Quote from: bassmaniac1903a really good default dark/black skin with a good adjustable size player, all

I agree, the look of the default skin is outdated and ugly.  One more modern and prettier one should replace it.  It would make new users more interested to keep XMPlay, instead of giving them the feeling to be suddenly back on Windows 98 and make them think the app is probably as outdated as the skin.

mrmudlord

#21
Quote from: LemuReposting my request from the 3.8 thread:

One last thing that's prevented me from switching from Winamp to XMplay fully: I'd love to be able to change the replay sample rate of an MP3. This would naturally change the pitch and also tempo.

The uses for such a function:
-  to breathe new life into a track you've heard a hundred times, to which your brain has become desensitized.
-  to experience the music more in-depth if you slow down a fast track a lot.

Please note that I'm not asking for time stretch (which usually produces unpleasant artifacts -- I'm talking about playing something sampled at 44100 Hz at say 42000 Hz or 45000 Hz, etc.).

I suggest granularity (units steps) 10 Hz or percentage of original rate (+/- integer percentage point) or, if you are brave, in cents (one half step of the Equal Temperament tuning system divides into 100 cents).

Hotkeys to increase, decrease and reset the deviation would be great!

Thank you!  :D

PS - The feature doesn't have to be in the core XMPlay. If it's done only via the DirectSound plugin, I'd be supper happy too!

What would be better is support for varying sample buffer lengths, which would also allow for custom resamplers and many other effects. Like libsox for resampling and libsoundtouch for pitch/tempo shifting for example.....

Y@nek®

#22
Last Edit: by Y@nek®
Quote from: mrmudlordPlease note that I'm not asking for time stretch (which usually produces unpleasant artifacts -- I'm talking about playing something sampled at 44100 Hz at say 42000 Hz or 45000 Hz, etc.).

I suggest granularity (units steps) 10 Hz or percentage of original rate (+/- integer percentage point) or, if you are brave, in cents (one half step of the Equal Temperament tuning system divides into 100 cents).



Very interesting. I never tryed this! Must check it. I see that we can edit and manually add 42000 Hz to resampling in XMPlay.

amit

#23
-Event style WASAPI output.

Muxson

#24
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.

But thanks Ian for the 32bit file support!!!

piovrauz

#25
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

#26
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:
QuoteAll 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

#27
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

#28
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

#29
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

#30
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

#31
Quote from: MuxsonI 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

#32
Quote from: Ian @ un4seenYeah, 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 @ un4seenNote 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... 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

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

saga

#35
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

#36
Any thoughts on the previous request? :)

Jimmy Neutron

#37
Quote from: sagaAny 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

#38
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

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



Reply Print
Go Up Pages 1 2 3 4 ... 25