Author Topic: Suggestions for 3.7  (Read 332504 times)

Pike84

  • Posts: 1398
Re: Suggestions for 3.7
« Reply #75 on: 7 Feb '11 - 08:34 »
It just seemed reasonable to let the developers know that, I for one, wouldn’t mind paying a fair price for such extras if they cannot give them away for free. It’s all I was saying.
Ok, that sounds reasonable. As Dotpitch said though, Ian does this alone (as far as anyone here knows), and his "main product" is still BASS (the audio library), that is commercial.

Still, no harm in hoping for new features, if they won't bloat the player :).

I'd rather have a donation option (on this site, not in the player) for the current XMPlay than a commercial version ;).
I could make a small donation every once in a while myself.

Jonesks

  • Guest
Re: Suggestions for 3.7
« Reply #76 on: 7 Feb '11 - 12:27 »
I'd rather have a donation option (on this site, not in the player) for the current XMPlay than a commercial version ;).

Yes, that could work too. I'm with you and Pike84 on this one. :)


Btw, oddiophile probably wasn't being sarcastic (he wants more DSP power in XMPlay).

No, of course he wasn't. Just letting his secret wishes out, if anything...  :)  I was actually amused, not offended at all.


Ian is the only developer of XMPlay, which makes it a bit more difficult to launch a commercial version with even more features.

Oh, I see. I knew he was the man behind it, but wasn't aware that XMPlay is entirely a one man effort. Kudos then!


A native VST wrapper sounds good though, and it can probably be constructed as a plugin.

Mmmmmusic to my ears!  :D


Ian @ un4seen

  • Administrator
  • Posts: 21987
Re: Suggestions for 3.7
« Reply #77 on: 7 Feb '11 - 15:34 »
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

And NoFlashPause also stops the flashing time when paused.

The time flashing is actually disabled regardless of the "NoFlashPause" setting :)

The update above also makes it possible for skins to define their own "paused" state for the play/pause button (placed below in the button_pause.bmp file) to be displayed instead of the flashing.

Oh, I see. I knew he was the man behind it, but wasn't aware that XMPlay is entirely a one man effort. Kudos then!

It's probably a bit unfair to call it entirely a one man effort, as there are others creating plugins and skins and support websites. A lot of the stuff that gets added is also user-suggested (the creeping size increase is all of you's fault ;)).

Btw, there are no plans for a commercial/paid version of XMPlay.

amit

  • Posts: 723
Re: Suggestions for 3.7
« Reply #78 on: 7 Feb '11 - 17:21 »
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


I appreciate the minimalistic approach :)

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.

Another related idea: now with the new advanced search syntax  , couldn't "locate in library" be transformed to "locate" and use the find window text? Finding chosen tracks' artists , for example , would become "%artist=x/%artist=Y...", finding their genres would become "%genre=x/%genre=y..." etc'.This will mean the located tracks will be marked both in the library and the playlist and could be selected easily. Then custom user find patterns (saved or remembered) could be added below the default "locate" list (after a splitter line ofcourse :) ).


garson

  • Posts: 148
Re: Suggestions for 3.7
« Reply #79 on: 7 Feb '11 - 17:44 »

The time flashing is actually disabled regardless of the "NoFlashPause" setting :)

The update above also makes it possible for skins to define their own "paused" state for the play/pause button (placed below in the button_pause.bmp file) to be displayed instead of the flashing.

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

Ian @ un4seen

  • Administrator
  • Posts: 21987
Re: Suggestions for 3.7
« Reply #80 on: 8 Feb '11 - 15:27 »
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

  • Posts: 148
Re: Suggestions for 3.7
« Reply #81 on: 8 Feb '11 - 21:26 »
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

  • Administrator
  • Posts: 21987
Re: Suggestions for 3.7
« Reply #82 on: 9 Feb '11 - 16:30 »
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

  • Posts: 148
Re: Suggestions for 3.7
« Reply #83 on: 9 Feb '11 - 16:44 »
I agree, but flashing will tell whether it is paused or not, rather then looking at progress bar.:)

Jimmy Neutron

  • Posts: 476
Re: Suggestions for 3.7
« Reply #84 on: 9 Feb '11 - 21:01 »
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

  • Posts: 2878
Re: Suggestions for 3.7
« Reply #85 on: 9 Feb '11 - 21:10 »
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]
« Last Edit: 10 Feb '11 - 06:33 by Dotpitch »

Cris

  • Posts: 232
Re: Suggestions for 3.7
« Reply #86 on: 9 Feb '11 - 21:41 »
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

  • Posts: 148
Re: Suggestions for 3.7
« Reply #87 on: 9 Feb '11 - 21:48 »
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

  • Posts: 476
Re: Suggestions for 3.7
« Reply #88 on: 9 Feb '11 - 21:58 »
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

  • Guest
Re: Suggestions for 3.7
« Reply #89 on: 10 Feb '11 - 07:25 »
Thank you Ian for disabling flashing time when paused (in latest stuff version)! :-)

Chinese Sausage

  • Posts: 424
Re: Suggestions for 3.7
« Reply #90 on: 12 Feb '11 - 21:22 »
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

  • Guest
Re: Suggestions for 3.7
« Reply #91 on: 13 Feb '11 - 01:12 »
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

  • Guest
Re: Suggestions for 3.7
« Reply #92 on: 13 Feb '11 - 01:14 »
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

  • Posts: 723
Re: Suggestions for 3.7
« Reply #93 on: 14 Feb '11 - 15:40 »
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

  • Administrator
  • Posts: 21987
Re: Suggestions for 3.7
« Reply #94 on: 15 Feb '11 - 17:51 »
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

  • Posts: 723
Re: Suggestions for 3.7
« Reply #95 on: 16 Feb '11 - 14:45 »
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: [Select]
/*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

  • Administrator
  • Posts: 21987
Re: Suggestions for 3.7
« Reply #96 on: 16 Feb '11 - 17:50 »
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

  • Posts: 723
Re: Suggestions for 3.7
« Reply #97 on: 18 Feb '11 - 15:58 »
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

  • Posts: 723
Re: Suggestions for 3.7
« Reply #98 on: 21 Feb '11 - 21:30 »
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

  • Administrator
  • Posts: 21987
Re: Suggestions for 3.7
« Reply #99 on: 22 Feb '11 - 16:33 »
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.