next »

[SmartOne]

Would this be more useful than right-clicking the prev/next buttons to skip cue sheet entries / subsongs?

Yes.

[raina]

Though separating CUE files into separate tracks would be ideal, short of that, could you please add one-pixel-wide markers on the seekbar at track borders?

You know, listening to files with cue sheets recently I sort of missed this feature. I still think right-clicking the prev/next buttons is handier for skipping tracks but the visual cue of a track change would be nice. If there is a seek bar fill graphic in the skin, you could slice those 1px markers off of that and when the marker has been passed, just revert it to the empty bar image. Or if that'd appear glitchy, use maybe the (usually darker) mouse-down shade of the seek bar, like you'd probably have to do with skins without a fill graphic.

[amit]

Though separating CUE files into separate tracks would be ideal, short of that, could you please add one-pixel-wide markers on the seekbar at track borders?

You know, listening to files with cue sheets recently I sort of missed this feature. I still think right-clicking the prev/next buttons is handier for skipping tracks but the visual cue of a track change would be nice. If there is a seek bar fill graphic in the skin, you could slice those 1px markers off of that and when the marker has been passed, just revert it to the empty bar image. Or if that'd appear glitchy, use maybe the (usually darker) mouse-down shade of the seek bar, like you'd probably have to do with skins without a fill graphic.

I don't think markers of sub-tracks in the seekbar need to come at the expanse of prev/next option. It is just more comfortable when moving the position slider. A scaler can be used for this although in very short sub-tracks or very small seekbar there may be a problem to show dense position markers together.

[Ian @ un4seen]

Here's an update with that feature to try...

   www.un4seen.com/stuff/xmplay.exe

It's a nice idea but I'm not really sure about it in practice, so it's an XMPLAY.INI option for now (add a "CueMark=1" line). Let me know what you think, ie. is it worth keeping and enabling by default.

[saga]

Looks pretty sweet. Maybe that could even be used for MOD subsongs?

[Cosworth]

Is there a way to put time track in the end of title in brackets?
I remeber that was in winamp. Very nice in mini mod.

[Dotpitch]

Is there a way to put time track in the end of title in brackets?

Do you mean the current playback time, or the total duration of the track?

[Cosworth]

Is there a way to put time track in the end of title in brackets?

Do you mean the current playback time, or the total duration of the track?

Only total duration of the track.

[amit]

Here's an update with that feature to try...

   www.un4seen.com/stuff/xmplay.exe

It's a nice idea but I'm not really sure about it in practice, so it's an XMPLAY.INI option for now (add a "CueMark=1" line). Let me know what you think, ie. is it worth keeping and enabling by default.

This is quite useful but my concern is about the aesthetics. Some skins need a little adjustment to fit this feature (colors, slider block in mask). Maybe an option to add a knob_cue or cue_scaler?

Another thing I thought of : instead of the flimsy 1 pixel lines (which isn't looking quite elegant IMO) could you make alternating colored blocks to represent the changing tracks? Something like this:

[Pike84]

Those tiny lines don't look too bad either (with default skin at least), but that's a nice alternative .

[saga]

Right now, when hovering the progress bar, its tooltip simply says "Position". Especially with the new cue markers feature, it would sometimes be nice to know what the actual position in time a certain position of this progress bar represents. Currently, the actual time is only displayed when dragging the progress bar, so could this behaviour maybe also be used when simply hovering the bar while a file is loaded? It could simply show the time or, to be more helpful, something like "Position (1:23)".

[amit]

In addition to what saga suggested , maybe the tooltip can show which subtrack is under the cursor when hovering the position slider?

[PAPABA]

Does XMPlay support 'always on top' feature

[PAPABA]

thnx, found it

[Ian @ un4seen]

Looks pretty sweet. Maybe that could even be used for MOD subsongs?

Here's an update with that...

   www.un4seen.com/stuff/xmplay.exe

I'm still not really sure about this stuff. It seems very fiddly to me, especially when there are a lot of cues/subsongs bunched up. I think it could be useful with a long position slider, so that there is more room for them to be spread out, but most skins are currently quite small with short sliders.

This is quite useful but my concern is about the aesthetics. Some skins need a little adjustment to fit this feature (colors, slider block in mask). Maybe an option to add a knob_cue or cue_scaler?

Another thing I thought of : instead of the flimsy 1 pixel lines (which isn't looking quite elegant IMO) could you make alternating colored blocks to represent the changing tracks? Something like this:

Yes, that could be a bit better, but I'm not sure it overcomes the fiddlyness

Right now, when hovering the progress bar, its tooltip simply says "Position". Especially with the new cue markers feature, it would sometimes be nice to know what the actual position in time a certain position of this progress bar represents. Currently, the actual time is only displayed when dragging the progress bar, so could this behaviour maybe also be used when simply hovering the bar while a file is loaded? It could simply show the time or, to be more helpful, something like "Position (1:23)".

One obstacle to that is that it would conflict with a little known feature (I think there may be as many as 1 skin using it ), which is that the current position is shown in the position slider's bubble when a skin doesn't contain a time display area.

[Dotpitch]

Right now, when hovering the progress bar, its tooltip simply says "Position". Especially with the new cue markers feature, it would sometimes be nice to know what the actual position in time a certain position of this progress bar represents. Currently, the actual time is only displayed when dragging the progress bar, so could this behaviour maybe also be used when simply hovering the bar while a file is loaded? It could simply show the time or, to be more helpful, something like "Position (1:23)".

One obstacle to that is that it would conflict with a little known feature (I think there may be as many as 1 skin using it ), which is that the current position is shown in the position slider's bubble when a skin doesn't contain a time display area.

But that feature is exactly what saga wants, he just wants it on every skin, right? Where did the 'Remove post'-button go?

The moment I posted this, I realized it's not the same. You could disable showing the hovered position time on those skins that use the bubble to show the current time, though.

[amit]

You could disable showing the hovered position time on those skins that use the bubble to show the current time, though.

Or show both?

[saga]

Could the "recent tracks" list be extended to also include track changes in web radios?

[stardust]

thought i'd toss my 2 cents in here

i'm fond of the surround effect, which seems good for widening the stereo image and focusing certain elements more to the centre, at least for ProTracker modules, where beats and drumloops are usually panned

however, the effect can be a little too much on some tracks, and the sound may become rather mushy...

so i was thinking, it would be great if there was a slider for this effect, that would allow us to set a preferred balance between the wet and dry signal (also being stored with saved settings) ♥

[stardust]

also, another one i'd like to see is file writing support for local media...how come it's only supported for streaming ?