Suggestions for 3.9

[tongub]

OK. Let me know if you do find that your new DAC doesn't work well with the WASAPI output plugin, and I'll bump event-driven support up the to-do list

So I got myself an async dac (Hifime 9018D) and had some crashes with Xmplay Wasapi although I don't know if it's because of push/event issue and I can't reliably reproduce them. For now it's doing fine with ASIO output though.

[rst]

I would have an interesting feaure request.

Keeping the 'next track' and 'previous track' buttons, during around 2 seconds, XMPlay jump in the tracklist to the next song that has a different album name.

And of course the all time features requests:

- Perform squared selections of tracks with mouse on the playlists
- Dettach a VIS window in order to see the playlist at the same time with VIS
- Show the current playing track over the VIS screen, when it is not full screen.

What you think about ?

[saga]

OpenMPT can now store artist information in MPTM files, and since this uses the same mechanism as OpenMPT extensions in IT/XM, I decided to make the artist field editable in those file formats as well (normally I am strictly against ever adding any new extensions to those formats, but artist information does not modify playback behaviour and is useful, so I made an exception there). It's stored in the same "STPM" block as the compatibility flag stuff you already implemented, so adding support for this should hopefully be straightforward. There is a now block with the magic bytes "AUTH" (yeah, this time the FOURCC is not backwards...), and it contains the artist name as an UTF-8 formatted string (not null-terminated, length is indicated by the chunk size). Would it be feasible to read this information out in XMPlay?
A file to try out this feature can be found here.

[Ian @ un4seen]

Yep, I'll add support for that in the next update.

[saga]

It would be great to have the playlist randomization feature in the context menu; I rarely use it, but since I do use it, I had to set up a shortcut for it, and I accidentally hit that shortcut more often than I'd like to. A context menu entry would avoid that.

[Ian @ un4seen]

Just to be sure, do you mean the "Shuffle" option or the "Random play order" option, and in what context menu would you like to see it? Both options are currently in the right-click menu of the "Random play order" button in the playlist panel. If you do accidentally shuffle the playlist, it is possible to undo that with the "List - Undo" shortcut (Ctrl+Z by default).

[saga]

Ah, I did indeed mean "Shuffle", I wasn't aware that it was placed in this context menu. I know I can undo it, but for that I first have to realize that I hit the shortcut.

[Krstfr]

Something cool would be the option to have multiple info windows open. It would be nice to see samples at the same time as message in different windows.

[kickgutsy]

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)?.

I votes for this, especially the one that looks similiar with logo on official website site. Though currently it can be manually changed by user, but that doesn't affect tray icon.

[quanta]

- Trim the amount of file opening dialogue boxes

Currently XMPlay uses 4 different dialogue boxes for 'Open file(s)', 'Add file(s)', 'Add Folder', 'Open folder' operations, which are too many. Furthermore, the 'Add Folder' and 'Open folder' dialogue boxes do not open from the last opened directory, creating awkward and inconsistent user interface experience. 'Open file(s)' and 'Add file(s)' can be merged by adding an 'Add' button to the 'Open file(s)' dialogue box, eliminating the need for 'Add file(s)' dialogue box. Furthermore, the 'Add' button does not close the 'Open file(s)' dialogue box, allowing files from multiple locations to be added within a single dialogue box session. Consequently, the 'Cancel' button is renamed to 'Close'. The 'Add Folder' and 'Open folder' dialogue boxes can be merged in similar manners.

However, the trimming can be done even further. 'Open file(s)' and 'Open folder' dialogue boxes can be merged into a single dialogue box with Explorer-style split directory and file views for files. Consequently, the 'Include sub-folders' and 'Ignore playlists & shortcuts' options are merged into the unified 'Open file(s)' dialogue box. Furthermore, the Open and Add buttons should be redesigned such that the operations can be applied to the selected directory and file objects, so no separate 'Add Folder' and 'Open Folder' dialogue boxes are necessary. As a result, all 4 dialogue boxes are merged into one without losing any feature.

As part of the dialogue box overhaul, XMPlay should also save the following properties of the united Open file(s) dialogue box: size, position, view settings. In addition, option to have the dialogue box to stay open after adding or opening file(s).

- Flexible skinning engine

The goal of this proposed skin engine is to move skin customization settings away from precompiled .dll files, so that most customizations can be done without altering the skin file. Conversely, skin makers can use the same script with different .dll files to achieve different looks. This redesign involves splitting up skin layout scripts and skin resources.

The skinning script will incorporate the ability to:
-Resize the image resource's bounding boxes, allowing only part of an image resource be shown in an image object (eg: button), or resizing or tiling of image resources be used in an image object.
-Widths of text objects so that sizes of the text field can be defined in units more friendly to skin makers (eg: number of characters, line heights, etc.). The final size of a text object is determined based on the fonts and their respective properties (eg: size, style, family) being applied to the text object.
- Alignment of objects relative to other user interface objects instead of just explicitly stating the location of UI objects in pixels, including the skin's bounding boxes. In addition, the ability to justify the position of multiple objects like word processors. For example, if a toolbar has left, right, and centre-aligned buttons, resizing the skin's width will maintain their horizontal positions relative to the skins, or even wrap extra buttons to successive rows if the width is too narrow. This facilitates the possibility of resizeable skins without recompiling.
- Ability to customize an UI object's transparency setting to underneath UI objects based on how much of an object's bounding box is occupied by graphical and text resources.

In addition to skin layout scripts, separate non-script customizations can be supported by a skin, so that a skin can have different colours or font size or even be resized without recompiling skin scripts or skin resources. The xmplay.ini will store separate skin settings for each skin, instead of sharing the common skin settings between skin. This will solve the long-standing forgotten skin settings bug affecting Windows Classic 2.1 skin[1].

[1] http://www.un4seen.com/forum/?topic=14320.msg101832#msg101832

[piovrauz]

While I'd like XMPlay to enhance its skinning capabilities (without getting bloated)... I must ask: who is supposed to develop and mantain said new skinning engine?
As far I know XMPlay is a 1 (good) man thing, and a skinning engine doesn't sound effortless... 

[saga]

The goal of this proposed skin engine is to move skin customization settings away from precompiled .dll files, so that most customizations can be done without altering the skin file. Conversely, skin makers can use the same script with different .dll files to achieve different looks. This redesign involves splitting up skin layout scripts and skin resources.

You're a bit to late for this, zip-based XMPlay skins have been available for quite a while already, and a few skins are already available in this format - of course this does not affect skins that have been last updated ten years ago. But as far as I remember, it was even possible to put a skin config file next to a compiled skin to change it?

[quanta]

The goal of this proposed skin engine is to move skin customization settings away from precompiled .dll files, so that most customizations can be done without altering the skin file. Conversely, skin makers can use the same script with different .dll files to achieve different looks. This redesign involves splitting up skin layout scripts and skin resources.

You're a bit to late for this, zip-based XMPlay skins have been available for quite a while already, and a few skins are already available in this format - of course this does not affect skins that have been last updated ten years ago. But as far as I remember, it was even possible to put a skin config file next to a compiled skin to change it?

The proposed skinning engine did mention rearranging and resizing UI elements relative to each other instead of just absolute coordinates, which is something current skinning engine lacks. To put it simply, UI layout script will resemble that of HTML+CSS combination, so formatting style of one UI object can be reused in another, and less burden need to reinvent the wheel. In any case, the current skinning engine has limitations that cannot be fixed that affects Windows Classic 2.1 (see topic Windows Classic 2.1 uses less accurate countdown timer [1]).

[1] http://www.un4seen.com/forum/?topic=17060.0

[piovrauz]

I'd like to see a small thing added to the track info window; when one is playing a stream, therere are streams that give you the title of what's playing; the info window displays it, but the track info shows only the stream name. would it be possible to show the current title too? Main use is easy copy of the title field, not possible on the info windows (there would be a lot of other stuff.
This or selectable text on the info window(s), whatever is less work.
Would something like this be possible?

[Jimmy Neutron]

Maybe I'm not understanding this.  I see the title&artist for streams.

Have you tried a different skin, or perhaps do a plain-vanilla temporary install and see what happens?

[piovrauz]

in the info window artist & track are visible, but in the track info window (playlist, track info) they are not.

[Jace]

'Track info window' refers to when you right-click on a playlist entry and pick 'Track info' (At least as far as I understood it)

[piovrauz]

it's as Jace said.

[Elrinth]

here's a suggestion.

be able to do some volume boost depending on plugin used.
in_nez is very low volume... so if I have like a mp3 after a .gbs I get deaf

[raina]

Save a volume boosting DSP setting per file type?

[saga]

...plus "Reset on new track" in the DSP amp setting, of course.

[raina]

Quite.

[AstralSoup Design]

I don't know about suggesting text wrapping for Track Info text area.
Call me insistent, but I believe skin scaling could be implemmented in XMPlay to close the gap between skinning and High-res screen issues (i.e. Buttons look too much small in my monitor).

[Rogue]

Hi, I am new here.
The player looks very simple and easy to use, but when I opened the big playlist I wanted to attach it to the player so that when I move the player to be moved with the player and the playlist was not moving with the player and there was no way to attach it.
Or make that small playlist resizable.
Also would be nice if this winamp dll file, I attached, could be used as output file.


PS: I found in options a checkbox to move playlist with player, but is a bit strange because it doesn't snap to main window it just stays where you put it

[piovrauz]

As far as I know the (big) playlist doesn't snap to the main windows of XMPlay, and the option you selected just "blocks" the position of the window.
I'd like the ability to snap the windows (main, media library, playlist, info, ...) too.
Regarding the "small playlist", that is not resizable, and its size  is determined by the skin.