Author Topic: Suggestions for 3.9 (Read 225301 times)

Ian @ un4seen · « **Reply #200 on:** 2 Jan '15 - 15:56 »

Ah yes, I see the problem now. I'll sort it for the next update.

Ian @ un4seen · « **Reply #201 on:** 5 Jan '15 - 16:00 »

The colors work great, but there is one little gotcha. Since the liststicky marker is painted over top of the listmark marker, even though the listmark marker is larger and very bright, it gets half covered over by the liststicky marker. It's not a big deal, the color change helps a bit, but it's still hard to pick it out at a glance (I have small fonts on a dedicated music laptop a few feet away).

I suppose if it painted the listmark marker over top of the liststicky marker it's lime green glory would be fully visible, but that would hide the fact that it's marked as "Don't auto-remove".

Any other ways to make the now playing marker really, really visible (or otherwise more visibly highlight the now playing track)?

Yep, the "Don't auto-remove" marker has to be drawn over the "now playing" marker, as the latter is larger. I think drawing them in that order also works best for skins that use bitmap markers (instead of the default triangles), eg. the "Don't auto-remove" marker could be a pin, like for a "sticky" forum thread. Anyway, if you don't really need the "Don't auto-remove" markers, here's an update with the option of removing them...

www.un4seen.com/stuff/xmplay.exe

Add a "NoStickyMark=1" line to your XMPLAY.INI file to remove the "Don't auto-remove" triangle markers (doesn't affect skins that include a bitmap marker).

Quote from: saga on 31 Dec '14 - 20:35

Yeah, it's only in the queue view. I don't make any use of the autoremove functionality, though.
It seems to consistently happen with certain files, but I don't know why. None of them have "don't auto-remove" checked in the context menu, just like all other files.

This should be sorted in the update above. Let me know if it's not.

Chinese Sausage · « **Reply #202 on:** 6 Jan '15 - 09:20 »

Thanks for the update Ian!

pilau · « **Reply #203 on:** 6 Jan '15 - 10:05 »

Multiple outputs to multiple audio devices - BASS library already allows this, why not XMPlay? This is one of the most powerful features to implement, and would really set XMPlay apart.

piovrauz · « **Reply #204 on:** 6 Jan '15 - 10:45 »

+1
and if it were configurable, it would really rock.

Muxson · « **Reply #205 on:** 6 Jan '15 - 11:52 »

+1 here too...

I'm using XMP for monitoring 20 streams that are routed to 6 audio cards.
My workaround was to create 20 separated players, each in its folder with specific skin, playlist, .ini file and all.
With that I can assign a sound card to each player but it's cumbersome. And any modification need to be replicated 20 times.
On top of it, I wrote a batch file to open and close all players, with command line switch (to load the correct playlist) and DDE commands to stop the players (in order to allow XMP to save parameters like volume and player position).
And one more "problem" is that all these players cannot be grouped in the Windows Taskbar because it is not multiple instances or the one .exe, it is multiple .exe

Muxson

Zzyzx · « **Reply #206 on:** 9 Jan '15 - 02:50 »

Quote from: Ian @ un4seen on 5 Jan '15 - 16:00

Yep, the "Don't auto-remove" marker has to be drawn over the "now playing" marker, as the latter is larger. I think drawing them in that order also works best for skins that use bitmap markers (instead of the default triangles), eg. the "Don't auto-remove" marker could be a pin, like for a "sticky" forum thread. Anyway, if you don't really need the "Don't auto-remove" markers, here's an update with the option of removing them...

Add a "NoStickyMark=1" line to your XMPLAY.INI file to remove the "Don't auto-remove" triangle markers (doesn't affect skins that include a bitmap marker).

Yeah, that works for me, thanks! My whole playlist is marked as Don't auto remove, with just my queued album tracks being auto-removed, so it's not a big deal for me not to see that marker in the playlist.

Maybe someday I'll get adventurous and try my own skin with bitmap markers...

xaos · « **Reply #207 on:** 10 Jan '15 - 04:02 »

just a thot .. as a someone who's built a few skins .. and also likes user options ... "NoStickyMark" should also apply to skins with the 'marksticky' bmp .. that way the author can include it but the user doesn't 'have' to use it.

(.. there ~~will be~~ is a marksticky included in the ~~next~~ update of Alloy ~~when i'm done messing with all the colors~~ )

edit: along with the previous thot about the "NoStickyMark" option, perhaps for end user ease of use, have the options : disable, use default, or use custom; if it exists. (would also make a good addition to an extended options page)

Y@nek® · « **Reply #208 on:** 11 Jan '15 - 14:20 »

What about VST plugins support? :-)

pilau · « **Reply #209 on:** 17 Jan '15 - 16:33 »

+1 This. And multiple outputs to multiple audio devices - BASS library already allows this, why not XMPlay?

saga · « **Reply #210 on:** 17 Jan '15 - 18:30 »

What's wrong with the Winamp VST plugin?

rst · « **Reply #211 on:** 17 Jan '15 - 20:14 »

i must keep suggesting for a new version the square selection with mouse on the paylists, it would be very useful !

Dhry · « **Reply #212 on:** 3 Feb '15 - 21:25 »

Hi Ian. Real small request - if the configuration window could be a bit larger, or preferably resizeable (rather than being locked at 546x344) it would be a little more ergonomically functional - esp with screens like Integration or support filetype lists for various input plugins.

Cheers
DRS

tongub · « **Reply #213 on:** 8 Feb '15 - 12:40 »

Is it possible to implement an option to choose Push or Even style for Wasapi, so people who use asynchronous dac can benefit?

Ian @ un4seen · « **Reply #214 on:** 9 Feb '15 - 17:35 »

Do you have a device that isn't currently working with the WASAPI plugin? I have heard of some devices not working properly with event-driven mode, but I think pretty much all devices should work with the push mode (which the WASAPI plugin currently uses).

tongub · « **Reply #215 on:** 11 Feb '15 - 07:27 »

Quote from: Ian @ un4seen on 9 Feb '15 - 17:35

Do you have a device that isn't currently working with the WASAPI plugin? I have heard of some devices not working properly with event-driven mode, but I think pretty much all devices should work with the push mode (which the WASAPI plugin currently uses).

I don't since I don't have an asynchronous DAC yet but I plan to. I heard async dac works better with event mode.

Ian @ un4seen · « **Reply #216 on:** 12 Feb '15 - 18:02 »

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

saga · « **Reply #217 on:** 14 Feb '15 - 16:14 »

Minor usability enhancement: I think it would be useful if the keyboard focus was reset to the find box in the find dialog when pressing the shortcut for opening the dialog, even if the dialog is already open. Right now, if the dialog was already open and the result list was focussed, it will stay focussed.

Ian @ un4seen · « **Reply #218 on:** 16 Feb '15 - 16:45 »

I'll look into it. In the meantime, it is possible to switch focus to the "Find" box by pressing Alt+F.

piovrauz · « **Reply #219 on:** 18 Feb '15 - 12:57 »

I will just ask for a cosmethic option: when using logarithmic volume show % in the tooltip instead of the attenuation in dB.
Thanks anyway.

piovrauz · « **Reply #220 on:** 5 Mar '15 - 21:27 »

Oh, last one was by myself...
Will ask another one then.

I'd like an option to not clean the played song list if a stream resetsby itself.
(so I don't lose the list if say, the wifi dsconnects)
Would this be possible?

Ian @ un4seen · « **Reply #221 on:** 6 Mar '15 - 18:04 »

I'm not sure about displaying the logarithmic volume setting as a percentage (it'll be a low number for most of the slider range), but here's an update that should retain the Message info window's "Recent tracks" list when reconnecting to the server...

www.un4seen.com/stuff/xmplay.exe

I presume that is the sort of thing you had in mind?

piovrauz · « **Reply #222 on:** 6 Mar '15 - 20:09 »

Yes, I was talking about the list displayed in Message info window.
Thanks a lot, tested and works beautifully.

I noticed the pre-amp gets reset after a disconnection: would it be possible to have it remember the last value?
I ask because I had it to a low setting, and when it restarted... I jumped!

Regarding the volume as a percentage, scrap that, I realized what I had in mind is nonsensical.
You not being sure about it amde me realize my error.

brycco · « **Reply #223 on:** 7 Mar '15 - 04:29 »

Suggestion: Re-order plugin priorities in options list
----------------------------------------------------------
Back when I had an unholy amount of winamp plugins, I would name them differently to change the order they appear in the plugin list, and xmplay would always use the one above it first

With that little trick, I could use two separate versions of the in_v2m.dll plugin, and if the first, newer plugin failed, it would normally get caught by the second older plugin.

Now I don't have any winamp plugins - and the trick doesn't work for xmp plugins, but it seems to load xmp-libxmp before xmp-openmpt, which I think is a better plugin for similar formats.

Instead of having to set filetype priorities on openmpt - why not allow the option to re-order the list, so that xmp-openmpt is loaded before xmp-libxmp.

Also, yes I know that libxmp has an option to disable specific formats, but that is just a coincidence, and sometimes a plugin wont have that. The ability to make all of openmpt (or any other plugin) a higher priority than libxmp has a lot of value and give finer control over what plugins are used and when.

NiZero · « **Reply #224 on:** 7 Mar '15 - 21:17 »

Hello to all and thank to creators of XMPlay for great player ever!

I have 2 suggestions:
1. «Toggle separate/unseparate song» option instead two menu options.
2. 10 or more band equalizer (actually, I need 20 Hz most of all).