Suggestions for 3.5

[Ian @ un4seen]

First: May I ask that sorting according to titles option will ignore the  new "cut" funtion and will sort according to the full untrimmed information?

That would make the sorting much slower. It currently uses the titles that are already in memory (as used in the playlist*), but it would have to regenerate the titles for all of the tracks in order to ignore the "cut" option. I'm not sure it's worth it.

* the full playlist, rather than the playlist panel (if that has a different format)

What I am trying to say is that for all regular actions from library/shell the files should be added to the playlist (even if they are added at the same time to the queue list) . The queue option will solely be used when you specifically ask to avoid the files from appearing in the list.

I think that should be possible with the recent "Apply to library and search result playing" addition to the Integration options page? With that enabled, I don't think anything will add to the queue without you specifically using the "queue" option or having the "Default action" set to "add to queue".

Personally, I don't like the way the queue is working right now. Especially because you cannot assign the same shortcut/mouse button to both queue and dequeue, like it was until now.

Here's an update to try, with a "Toggle queuing" option in the Playlist options page...

   www.un4seen.com/stuff/xmplay.exe

That should give pretty close to the old behaviour. It's not exactly the same though, as it is now queuing tracks rather than playlist entries, eg. trying to queue 2 playlist entries of the same track will result in a single queue entry.

Something must've gone awry, because now trying to queue tracks normally with middle mouse button results in XMPlay crashing quietly (queuing via right-click menu still seems to work) .

Oops, I think that should be sorted in the update above. I'm not sure that would explain the extra buttons not working though, so if you still have that problem, do you have some special mouse driver/software installed, and does removing/disabling that make any difference?

Oh, and one other small thing... when using the Find dialog, I search for some tracks, press Alt+R to jump to the results list, select the track(s) that I want to play, pres SPACE and... a popup menu appears (the right click popup menu). Is this intentional?

That was intentional, but the addition of the "Apply to library and search result playing" option probably makes the menu less necessary, so it has been removed now.

[Cris]

Works almost perfectly.

The only thing that's still missing from the Find dialog is this: in the past, when selecting multiple results and pressing SPACE (or right-click -> Play), the first selected track would start playing and the rest would get queued. Right now, this doesn't happen (the first selected track starts playing, but the rest don't get queued).

It's not much of a problem, since selecting the tracks in the Find dialog also selects them in playlist, so I can just use a global hotkey to Queue.

Thank you for this fast "fix".

[Pike84]

I'm not sure that would explain the extra buttons not working though, so if you still have that problem, do you have some special mouse driver/software installed, and does removing/disabling that make any difference?

I had the Razer software installed, but removing it didn't help; the button presses were still ignored. Besides, the software has useful stuff for me (different button configurations etc), so I wouldn't really like to be off with it just for this.

The queue toggling option works, but I think you should still be able to queue tracks multiple times with it checked. The most obvious solution would be just allowing the "queue" option, from the right click menu, to only add to the queue.

[saga]

I am trying to open zipped online modules from a PLS file, but it seems that they're not added to the playlist anymore after having added them in a previous session already (they're not in the playlist anymore, obviously). I'm sure that I haven't changed any settings in XMPlay. Did that behviour change, and how can it be reverted?

[Ian @ un4seen]

I had the Razer software installed, but removing it didn't help; the button presses were still ignored. Besides, the software has useful stuff for me (different button configurations etc), so I wouldn't really like to be off with it just for this.

That's strange, it seems to be working fine with a Logitech mouse on XP and Vista here (no extra software installed). What Windows version are you using? I think I may have to send you a debug version to find out what messages (if any) XMPlay is receiving for the extra buttons.

I am trying to open zipped online modules from a PLS file, but it seems that they're not added to the playlist anymore after having added them in a previous session already (they're not in the playlist anymore, obviously). I'm sure that I haven't changed any settings in XMPlay. Did that behviour change, and how can it be reverted?

I was unable to reproduce that myself, although perhaps I didn't go about it in the right way (I'm unsure about the "previous session" business). Do you have an example PLS/URL to reproduce the problem with?

Btw, regarding the queue stuff... I'm considering switching it back to the old system (of queuing playlist entries) but keeping the "Toggle queuing" and "Dequeue" options to allow tracks (playlist entries) to be queued multiple times. Does anyone have any thoughts/objections on that?

[amit]

1.

Here's an update to try, with a "Toggle queuing" option in the Playlist options page...

   www.un4seen.com/stuff/xmplay.exe

That should give pretty close to the old behaviour. It's not exactly the same though, as it is now queuing tracks rather than playlist entries, eg. trying to queue 2 playlist entries of the same track will result in a single queue entry.

A small thing...If toggle option is selected there is no need in the context menu for "dequeue" entry - even grayed. Is it?

2.
Is it possible to add a "disc" tag for title formatting?
Maybe it is possible to add a parameter for user defined tag? for exmample %9='input box' where people could put in "album artist", ,"performer" , "disc" or any other...

[Pike84]

What Windows version are you using? I think I may have to send you a debug version to find out what messages (if any) XMPlay is receiving for the extra buttons.

I'm using XP SP3. You can send the debug version in my e-mail, I can probably get around to running it in a day or two.

Btw, regarding the queue stuff... I'm considering switching it back to the old system (of queuing playlist entries) but keeping the "Toggle queuing" and "Dequeue" options to allow tracks (playlist entries) to be queued multiple times. Does anyone have any thoughts/objections on that?

I'm ok with that

[Cypress]

i must say that i totally dislike the new queue mode because after you have queued a track and thats supossed to be the last queued track xmplay just jumps to the first track in the playlist and not in the position where it was supossed to be....
please i vote for the old queue mode that was the GOOD QUEUE....

Salu2

[Ian @ un4seen]

Is it possible to add a "disc" tag for title formatting?
Maybe it is possible to add a parameter for user defined tag? for exmample %9='input box' where people could put in "album artist", ,"performer" , "disc" or any other...

The title formatting uses the tags stored in the library, so it isn't currently possible to refer to anything other than the standard tags stored there. One thing I was considering for 3.5 was having the library store all tags, which would then be available for searching and title formatting. That could greatly increase the size of the library (and memory usage) though, so I'm not sure.

[amit]

The title formatting uses the tags stored in the library, so it isn't currently possible to refer to anything other than the standard tags stored there. One thing I was considering for 3.5 was having the library store all tags, which would then be available for searching and title formatting. That could greatly increase the size of the library (and memory usage) though, so I'm not sure.

Scanning all tags will lead also to more vulnerability to errors. Right? It will also mean more scanning times?

The question is also how do we access all these new tag information? In search window only? by library columns?

I can only suggest similar to what I already said regarding the disc tag:
An input box to enter specific tags you want to be added to xmplay. You could write there : "performer;album artist;disc" so only these tags would be additionally scanned.

[Cris]

Btw, regarding the queue stuff... I'm considering switching it back to the old system (of queuing playlist entries) but keeping the "Toggle queuing" and "Dequeue" options to allow tracks (playlist entries) to be queued multiple times. Does anyone have any thoughts/objections on that?

I, for one, have nothing against this idea.

One thing I was considering for 3.5 was having the library store all tags, which would then be available for searching and title formatting. That could greatly increase the size of the library (and memory usage) though, so I'm not sure.

If this has to be done (as in: if most users want and need it), then the best approach would be the one suggested by amit:

An input box to enter specific tags you want to be added to xmplay. You could write there : "performer;album artist;disc" so only these tags would be additionally scanned.

This way, users who don't need the extra-fields won't have to suffer from higher resource usage. Also, I guess most of the users don't even have those tags filled in the media files (I know I don't), so keeping extra empty fields in memory/library would be a waste.

[Cris]

I just realized: when playing a track from the Find dialog, it's automatically moved to the end of the playlist...
This made made a complete mess of the order of the tracks.

[saga]

Cris: Do you happen to have "[x] move existing" on the "playlist" tab ticked?

[Pike84]

A really minimal thing..

There doesn't seem to be a way to stop XMPlay from listing dead tracks for recovery. Since I have never had use for this feature, and probably never will, I'd rather it didn't do that at all. It doesn't really bother me much, just the idea that there is something completely useless going on. Also, it's possible that some people might want to turn it off for privacy reasons, since it is a kind of a track history.

[Cris]

Cris: Do you happen to have "[x] move existing" on the "playlist" tab ticked?

Yes, I do. I like that feature (it helps me keeps tracks grouped when adding new tracks).
I don't really have a special order in my playlist, because I use Random play order all the time (except when I queue some tracks). But I like to keep the tracks grouped by folder, which is exactly what "Move existing" does.

Yes, I know that the last thing I posted is caused by that option being enabled (I figured it out a little after I posted). But, as I see it... the new queue behavior added very few features and "broke" many other.

[Ian @ un4seen]

Scanning all tags will lead also to more vulnerability to errors. Right? It will also mean more scanning times?

I'm not sure what you mean by errors, but I don't think the scanning time would change very much. The existing tracks would need to be rescanned initially for the extra tags though, and that could take a while with a large library/list. That would be the case for any number of extra tags, ie. all of them or just a select few.

The question is also how do we access all these new tag information? In search window only? by library columns?

I was thinking of the "Track info" window and library.

Anyway, it probably won't happen in time for 3.5 now, but perhaps something for the future (perhaps along with tag writing).

There doesn't seem to be a way to stop XMPlay from listing dead tracks for recovery. Since I have never had use for this feature, and probably never will, I'd rather it didn't do that at all. It doesn't really bother me much, just the idea that there is something completely useless going on. Also, it's possible that some people might want to turn it off for privacy reasons, since it is a kind of a track history.

XMPlay doesn't keep a separate list/history of dead tracks, but rather just marks tracks as dead if it can't find/open them, ie. all the dead tracks (listed in the "Dead" options page) can be found in the playlist and/or library. By default, XMPlay will check whether each of the tracks (local files) exist shortly after it is launched, but that can be disabled by adding a "NoCheckDead=1" XMPLAY.INI entry.

Here now is an update in which the queue has been switched back to the old system (of queuing playlist entries), but with some of the new stuff (eg. "Toggle queuing" and "Dequeue") merged into it...

   www.un4seen.com/stuff/xmplay.exe

Please report any problems, eg. anything broken in the merger.

[Pike84]

XMPlay doesn't keep a separate list/history of dead tracks, but rather just marks tracks as dead if it can't find/open them, ie. all the dead tracks (listed in the "Dead" options page) can be found in the playlist and/or library.

Ah yes, I got confused since the playlist and the library have separate "remove" functions (obviously) and I hadn't used the library view for a while.

[amit]

Another suggestion:

It is a little frustrating scrolling through long lists. The scrollbar rolls relatively to the list length thus jumps great distances and wheel scrolling is many times too slow.

What about adding middle click auto-scroll function? Similar to firefox and other software : middle clicking and moving the pointer will scroll the list to that direction. Moving away from the clicked point will scroll faster and vice versa.

[REVerdi]

I'm sorry, but I do not understand the need for the queue. I believe that if the design of XMPlay is to have only a single playlist, then the queue should not exist. Everything should be queued on that single playlist. If not, then it would be better to make the XMPlay a program with multiple playlists.

[Cypress]

Mhhh... the Good Queue is back Cool...!! thanks..

the queue is very very usefull 'cause i usually listen to whole discographies instead of custom playlists just drag and drop the folder artist(s) i want to listen and then middle clicking the songs i want, i could use custom playlist but to me that's creating garbage files unless you take care of them because surelly they're going to be hundreds of PLSs...

anyways the queue has its purpose and i really like it...

Salu2

[Dotpitch]

It is a little frustrating scrolling through long lists. The scrollbar rolls relatively to the list length thus jumps great distances and wheel scrolling is many times too slow. What about adding middle click auto-scroll function? Similar to firefox and other software : middle clicking and moving the pointer will scroll the list to that direction. Moving away from the clicked point will scroll faster and vice versa.

That scrolling feature is not built into Firefox, it works in almost every application. It would be a nice feature, but I'm not sure whether it would work with middle-click queueing. Have you tried 'List nav - Page up/down'?

I'm sorry, but I do not understand the need for the queue. I believe that if the design of XMPlay is to have only a single playlist, then the queue should not exist.

I disagree, queueing still has a purpose if you use a single playlist, as I mentioned.

Everything should be queued on that single playlist. If not, then it would be better to make the XMPlay a program with multiple playlists.

Try the latest stuff version, it has the old queue system.

[amit]

That scrolling feature is not built into Firefox, it works in almost every application.

I am still using windows xp so I don't know about later windows versions. I think still every application implements this feature separately.

It would be a nice feature, but I'm not sure whether it would work with middle-click queueing.

I don't think there would be a conflict with  middle clicking queue: Middle clicking without movement is for queue/de-queue; middle click + movement is for auto scroll. In other apps there are separate actions to middle click and autoscroll.

Have you tried 'List nav - Page up/down'?

yes , I know of this...Thanks

 

[Ian @ un4seen]

It is a little frustrating scrolling through long lists. The scrollbar rolls relatively to the list length thus jumps great distances and wheel scrolling is many times too slow.

What about adding middle click auto-scroll function? Similar to firefox and other software : middle clicking and moving the pointer will scroll the list to that direction. Moving away from the clicked point will scroll faster and vice versa.

I'm not sure about that, but here's an update in which clicking in the scroller area (but not on the scroller itself) will jump a page up/down...

   www.un4seen.com/stuff/xmplay.exe

[amit]

It is a little frustrating scrolling through long lists. The scrollbar rolls relatively to the list length thus jumps great distances and wheel scrolling is many times too slow.

What about adding middle click auto-scroll function? Similar to firefox and other software : middle clicking and moving the pointer will scroll the list to that direction. Moving away from the clicked point will scroll faster and vice versa.

I'm not sure about that, but here's an update in which clicking in the scroller area (but not on the scroller itself) will jump a page up/down...

   www.un4seen.com/stuff/xmplay.exe

OK...

Now how about imitating windows behavior ? keeping left mouse button pressed on the scroller will move up/down the list by one page, then a short delay and then quickly scroll pages?

[Tsorovan]

I'm sorry, but I do not understand the need for the queue. I believe that if the design of XMPlay is to have only a single playlist, then the queue should not exist. Everything should be queued on that single playlist. If not, then it would be better to make the XMPlay a program with multiple playlists.

I've never seen a proper use for it either, but it doesn't get in the way so why care a lot?