Author Topic: Suggestions for 3.9 (Read 226447 times)

saga · « **Reply #100 on:** 8 May '14 - 23:34 »

There's an "including sub-folders" checkbox in the add folder dialog.

Jimmy Neutron · « **Reply #101 on:** 9 May '14 - 13:28 »

Also, you can right-click the monitored folder entry.

Elrinth · « **Reply #102 on:** 9 May '14 - 23:59 »

Quote from: piovrauz on 27 Dec '13 - 10:22

Nah, he just remember the old days (and old PCs specs): my old Pentium 133MHz was able to decode a 128kbps mp3, with winamp, but you couldn't do anything else at the same time, not even scrolling a text file... Nowadays cpu are so fast that decoding mp3 uses anlmost no cpu.

Encoding is another thing, obviously it'll always use 100% cpu (well, if the sys is fast enough) to use the less time possible, which should be good (faster encode).
If one would go cuda/opencl/whatever, obviously that will offload the cpu but at the risk is that the encoder won't be reliable as one encoding on cpu is.

My old 486 DX4 100mhz running win95 was able to play a 128kbps mp3 aswell in winamp.

* One suggestion I have for 3.9 is to make the default setting in Miscellaneous section that Track looping/ending to have Loop drowdown set to Never by default and Limit to 0. (SNES songs will continue for ever if you have the default settings xmplay has right now)
* Another suggestion is that MOD section should have Interpolation off and ramping off and pan separation 30.
* Also under Playlist section the Ignore filetypes inputbox could have the following default values: avi mpg mpeg txt jpg jpeg gif png bmp

What do you guys think about these default values?

saga · « **Reply #103 on:** 10 May '14 - 13:51 »

Quote from: Elrinth on 9 May '14 - 23:59

* Another suggestion is that MOD section should have Interpolation off and ramping off and pan separation 30.

30% is an absolutely senseless value because no tracker in this world uses it as the default, meaning that XMPlay would by default sound different from any tracker for no good reason. If you like 30% better, you are welcome to change it to that value and even use per-file or per-format settings to only use 30% when needed. 50% is what every other tracker uses, too. Same goes for the looping stuff, you can activate these settings per file type (e.g. for SPC). Just because one specific plugin doesn't behave you want by default, why sacrifice the default loop behaviour of the built-in mod player?

HellMan666 · « **Reply #104 on:** 11 May '14 - 00:57 »

link the player to your forum profile, so you can add your forum avatar pic or url via the xmplay app and have it automatically updated/sync to your forum profile, if possible

rst · « **Reply #105 on:** 11 May '14 - 04:04 »

in my opinion,

a square selection with mouse in the playlist. A must have !!!

piovrauz · « **Reply #106 on:** 11 May '14 - 07:10 »

I'd add the possibility to select text in the info/message windows, so one could select just some and not copy all of it like it's now.

jbb666 · « **Reply #107 on:** 13 May '14 - 01:36 »

Would you be able to add the ability to bind shortcut keys to mouse buttons.

Chinese Sausage · « **Reply #108 on:** 13 May '14 - 04:24 »

I will love to have XMPlay 100% compatible in Linux.
Linux is what I use at work and is the future. I am forced to use Audicious (not a bad player actually) as a second choice because of XMPlay's partial compatibility in Linux (through Wine).

piovrauz · « **Reply #109 on:** 13 May '14 - 10:10 »

Seconded (but I said it already in the past)...
Audacious is a fine program, but XMPlay would be king.
Sadly wine doesn't support it well.
I suppose multi platform compiling for XMPlay will requires some hard work, or just lot of time.
Not holding my breath, but I'd like for it to happen.

saga · « **Reply #110 on:** 13 May '14 - 10:14 »

Quote from: Chinese Sausage on 13 May '14 - 04:24

I will love to have XMPlay 100% compatible in Linux.
Linux is what I use at work and is the future. I am forced to use Audicious (not a bad player actually) as a second choice because of XMPlay's partial compatibility in Linux (through Wine).

Maybe it would make more sense to post bugs on WineHQ rather than telling Windows programmers to "fix" their stuff. Wine isn't perfect.

HellMan666 · « **Reply #111 on:** 14 May '14 - 04:25 »

a transparent and/or custom wallpaper change background option, give a playlist or library, both even better, a bit more of a custom look, making it more me and less default, other than lack of an ability to change a few colours and add your own BG image like i did with mine in the image, its simply an awesome media player

frozenat99 · « **Reply #112 on:** 17 May '14 - 09:28 »

add automatic to resolution (plays 16 bit if the file is 16 bit and 24 bit if it is 24 bit)

Alt · « **Reply #113 on:** 20 May '14 - 21:18 »

Quote from: frozenat99 on 17 May '14 - 09:28

add automatic to resolution (plays 16 bit if the file is 16 bit and 24 bit if it is 24 bit)

+1
Optional of course, but for all outputs.
----
"Extended list" would look better if it will use 'formatting string' from "playlist panel"

saga · « **Reply #114 on:** 24 May '14 - 14:44 »

Currently, the "Current track - next" shortcut either advances to the next track in the playlist, or a random track, depending on the play mode. This is exactly the expected behaviour that I want. However, sometimes it would be nice to have a shortcut for playing the next track in the playlist even in random play mode. I guess assigning "list nav - next" and "play" to the same shortcut would only work when the currently playing track is already selected. So a new shortcut would probably a good idea.

Dotpitch · « **Reply #115 on:** 24 May '14 - 21:06 »

Quote from: saga on 24 May '14 - 14:44

I guess assigning "list nav - next" and "play" to the same shortcut would only work when the currently playing track is already selected. So a new shortcut would probably a good idea.

But you could add 'List nav - Jump to current' to that same shortcut to ensure that, right?

Quote from: frozenat99 on 17 May '14 - 09:28

add automatic to resolution (plays 16 bit if the file is 16 bit and 24 bit if it is 24 bit)

What would be the benefit of this? I guess the resolution of the DAC is fixed, so someone has to do the padding anyway.

saga · « **Reply #116 on:** 25 May '14 - 20:15 »

Quote from: Dotpitch on 24 May '14 - 21:06

Quote from: saga on 24 May '14 - 14:44
I guess assigning "list nav - next" and "play" to the same shortcut would only work when the currently playing track is already selected. So a new shortcut would probably a good idea.
But you could add 'List nav - Jump to current' to that same shortcut to ensure that, right?

Indeed, somehow I completely missed that shortcut!

That does the trick.

Another thing I noticed is that it's difficult to enqueue tracks from the find dialog using merely the keyboard. Using space, you can play the selected track, however enqueuing is only possible through the context menu (I know it can be reached through the application key, but that's clumsy). Using something like ctrl-space to enqueue tracks from the find dialog would be a nice improvement.

Swallagoon · « **Reply #117 on:** 30 May '14 - 12:09 »

+1 to playlist tabs. They would be a really nice feature.

Chinese Sausage · « **Reply #118 on:** 12 Jun '14 - 06:09 »

+2 Tabbed Playlist. The already mentioned Audicious player in Linux has "Tabbed Playlist" feature in its "Winamp Interface". The user can shift between playlists by pressing the Tab button (and Shift + Tab in reverse direction). I would love it if this feature can be implemented in XMPlay, as well as a Linux port of the player (as mentioned earlier on this post), if it's possible!

Y@nek® · « **Reply #119 on:** 12 Jun '14 - 17:12 »

- 1 playlist tabs.

If you decide to implement this useless function - please add an option to disable it by setting.

saga · « **Reply #120 on:** 13 Jun '14 - 12:15 »

It would be really useful if overriden tags were preserved for sub tunes when splitting them. Right now, you have to copy them over manually from the original library entry to the sub songs.

Chinese Sausage · « **Reply #121 on:** 13 Jun '14 - 15:46 »

I tried again to use XMPlay in Linux Mint through Wine. Unfortunately still does not function well enough. In the meantime, I had to revert using Audacious. Even if the Wine Project somehow figures it out to emulate XMPlay well in Linux, still it would be very nice to have a port in Linux as well, as Audacious (and many other Linux audio players) lacks many of the details and features that XMPlay does well.

Chinese Sausage · « **Reply #122 on:** 13 Jun '14 - 16:47 »

The following skins work better with XMPlay in Linux:

- A-round series
- Aiwa series
- Euphoria
- LiteB
- MikamiCentre
- Min (blue)
- Opus (probably the most stable skin)
- Royale Vista
- XMP Underground Radio
- Zune

saga · « **Reply #123 on:** 13 Jun '14 - 20:25 »

Quote from: Chinese Sausage on 13 Jun '14 - 15:46

Even if the Wine Project somehow figures it out to emulate XMPlay well in Linux

I'm pretty sure XMPlay is not in their top priority list of programs to get running, so if you want to help, you should report your precise findings of where XMPlay fails to function as expected to the WineHQ bug tracker. This will at least increase the change of the issue getting fixed.

Alt · « **Reply #124 on:** 14 Jun '14 - 09:48 »

Would be nice to have "24 bit data in a 32-bit package" Resolution like in AIMP3 & JRiver. Something like option of ASIO plugin ("24 bit padded to 32") but for DS & WASAPI outputs (which are more preferable for some users).