▲

[Ian @ un4seen]

Ian, can you please add option for play/pause button to flash after closing XMplay in paused state?

It isn't still paused when XMPlay is reloaded because the output device isn't initialized yet (it won't be until playback is started).

[garson]

Ian, can you please add option for play/pause button to flash after closing XMplay in paused state?

It isn't still paused when XMPlay is reloaded because the output device isn't initialized yet (it won't be until playback is started).

Yeah, but progress bar isn't on beggining, so it is somehow aware that it should resume playback?

[Ian @ un4seen]

The difference between paused and stopped is basically just whether the output device is initialized. XMPlay will seek to the closing position, but it won't initialize the output device yet, so the playback status is stopped rather than paused.

Whether paused or stopped, pressing the Play button will begin playback, so I don't think it really makes a massive difference

[garson]

I agree, but flashing will tell whether it is paused or not, rather then looking at progress bar.

[Jimmy Neutron]

I don't understand.

• If paused, press play to get the music going
• If stopped, press play to get the music going

What's the difference?  Maybe you can explain what I'm missing....

[Dotpitch]

What's the difference?  Maybe you can explain what I'm missing...

If you're playing a file and you pause it, the play-button will flash between the playing and pausing symbol. If you then close with position saved and re-launch XMPlay, playback will still be pausedstopped at the same position, but the button will not be flashing.
garson would like it to flash, because he uses that as as indicator of playback being paused. Ian designed it not to flash, because it's actually an indicator of whether the output device has been initialized.

[edit]Cris, you're completely right .[/edit]

[Cris]

re-launch XMPlay, playback will still be paused at the same position

Actually, what Ian said is that, when XMPlay is relaunched, the player is stopped, not paused, even though the progress indicator shows the previous song position. And since the player is stopped, not paused (therefore, the output device is not initialized - yet), the play button doesn't flash.


On a sidenote, would it me too much of a hassle to reintroduce the time blinking while the song is paused, at least as (another) secret option? I liked it better that way (personal opinion).

[garson]

I don't understand.

• If paused, press play to get the music going
• If stopped, press play to get the music going

What's the difference?  Maybe you can explain what I'm missing....

It is not about that, it's just that I would like to know if I previously paused it or not.

But thanks, Dotpitch anyway.

I would also like time to flash like earlier.

[Jimmy Neutron]

What's the difference?  Maybe you can explain what I'm missing...

garson would like it to flash, because he uses that as as indicator of playback being paused.

OK, I never considered that it would be significant.

[en]

Thank you Ian for disabling flashing time when paused (in latest stuff version)! :-)

[Chinese Sausage]

Make the info window easier to "stick" on top, sideways or bottom to the main window (as in Winamp or AIMP2). It will make thing a lot better, and it would be as hard to move the info window in the exact place all the time, specially with integrated touchpads in laptops, which can sometimes be a bit difficult.

Cheers!

[Qtronix]

I have a suggestion that I always look for in audio players.

Crossfading based on dB-levels.

ie. make xmplay start playing from where the level is higher than a certain dB.
The same for where it drops and don't rise again over a certain dB to make it fade to the next song over a desired duration, say 2500 ms.

[Qtronix]

I have a suggestion that I always look for in audio players.

Crossfading based on dB-levels.

ie. make xmplay start playing from where the level is higher than a certain dB.
The same for where it drops and don't rise again over a certain dB to make it fade to the next song over a desired duration, say 2500 ms.

This could for example be an output plugin or something?

[amit]

In the meantime, although not quite as convenient as a right-click menu, you could use the "Find" history to do it

On that note, the history is now accessible via the quick find option, by pressing Page Up/Down...

   www.un4seen.com/stuff/xmplay.exe

This is nice though it isn't ensuring specific search patterns to stay indefinitely available. If you prefer going this road , maybe a check box can be added in the find window? It will tell xmplay to remember ticked patterns with no regard to the history.

What do you think about this suggestion? Or would the original suggestion be better as an easy access right click menu?

[Ian @ un4seen]

I'm still undecided about a separate option, but regarding a right-click menu, here's an update that makes the search history also accessible via the search button's right-click menu...

   www.un4seen.com/stuff/xmplay.exe

Regarding keeping items in the search history, although perhaps not as convenient as it could be, that can be achieved by selecting and applying an item in the "Find Tracks" window, which will move the item to the top of the history (furthest from being removed). Note only items entered in the "Find tracks" window get added to the history; the quick find option doesn't add to it.

[amit]

I'm still undecided about a separate option, but regarding a right-click menu, here's an update that makes the search history also accessible via the search button's right-click menu...

   www.un4seen.com/stuff/xmplay.exe

Regarding keeping items in the search history, although perhaps not as convenient as it could be, that can be achieved by selecting and applying an item in the "Find Tracks" window, which will move the item to the top of the history (furthest from being removed). Note only items entered in the "Find tracks" window get added to the history; the quick find option doesn't add to it.

Right clicking on the search button seems reasonable , as this option doesn't refer to selected tracks.

As for keeping certain searches or giving them logical names : Previously I suggested a checkbox similar to the global keyboard shortcut checkbox , to indicate which searches are to stay permanently available. Another way could be to simply use the search syntax : writing a text flag will keep the search from deleting , further more - if a certain text sign would indicate a name for a search combination it can also indicate it to stay permanently. 

for example :

Code SelectExpand

/*classical  music*/ %genre=opera/%genre=classical/%genre=chamber/%genre=symphonicThis will mean 'classical music' will be shown in the search list instead of the actual terms and ofcourse - it won't be deleted because of old age.
 

[Ian @ un4seen]

The histories (search/url/folder) currently each have a fixed limit of 20 entries, and an entry will only be removed to make space for a new one. The entries aren't timestamped and won't be removed when they reach old age, though it is true that the last/oldest will be the one to go when space is needed.

Permanent entries won't work well with a fixed size history, eg. you might want more than 20 permanent entries. So they would probably require a separate list, but I'm not sure what that would look like

[amit]

Permanent entries won't work well with a fixed size history, eg. you might want more than 20 permanent entries. So they would probably require a separate list, but I'm not sure what that would look like

Removing the limit of 20 for permanent searches is welcome but won't it have a side effect on memory usage or performance?  If those lists are to be separated do you think they should be separated in the gui as well?

[amit]

A little more about the search behavior :

When does it checks for matches? Does it look for matches only when 'find window'/'quick find' are active?

If changing a track info after the search is already set , the search results aren't updated. For example - if I change the rating of a track , thus excluding the track from the search criteria ,its status isn't updated and it stays marked. Can this be changed?

[Ian @ un4seen]

Permanent entries won't work well with a fixed size history, eg. you might want more than 20 permanent entries. So they would probably require a separate list, but I'm not sure what that would look like

Removing the limit of 20 for permanent searches is welcome but won't it have a side effect on memory usage or performance?  If those lists are to be separated do you think they should be separated in the gui as well?

Yes, I think a separate list would be better for your presets, rather than making them permanent entries in the search history.

A little more about the search behavior :

When does it checks for matches? Does it look for matches only when 'find window'/'quick find' are active?

If changing a track info after the search is already set , the search results aren't updated. For example - if I change the rating of a track , thus excluding the track from the search criteria ,its status isn't updated and it stays marked. Can this be changed?

A track's search match status should be updated after any info changes, but that stuff hasn't yet been updated to consider the info used by the new search options. Here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still have any trouble with it.