Topic: XMPlay 2.7 suggestions

[Brightguy]

Vintage also has the volume slider in mini-mode.

[Ralesk]

<CHEEKY>I /don't/ want the volume slider in mini-mode</CHEEKY> :laugh: :laugh: :laugh:

[Zarggg]

Agree.  Let the skin authors decide what goes on their skins.

[Paul]

First Thanks for making an excellent media player. Tracker music sounds good (much better than Winamp ever did)

Anyway an idea about visualisations, it would be good to have an Option to display them full screen using OpenGL or DirectDraw modes. :idea:

[Pike84]

I'm sure someone mentioned this before, somewhere, sometime, but I'll put it here for clarity anyway: Updating the ID tags without having to play the track. It'd be really nice thing, and surely not too hard to add.

[Torkell]

Updating the ID tags doesn't happen because (if I remember right) the tags are at the start of the MP3/OGG file and are in a variable-length block. Changing the tags would force the streaming to be recalculated, as if I'm right the streaming works by reading in from the file as needed and letting windows manage the current byte pointer (or something like that). The only thing you can do with a streamed file is append to it. Sticking stuff in before the current read position just kills the whole thing (as the plugins don't exactly write to the file through XMPlay).

[Jace]

What about if you change the tag of a song which is NOT playing.. It wouldn't need to recalculate anything, but still it won't update (on the playlist) until the song starts playing next time..
And about the now-playing song's changed tag; perhaps it could update and refresh it on the list as soon as the song is finished? =)

[Torkell]

What about if you change the tag of a song which is NOT playing.. It wouldn't need to recalculate anything, but still it won't update (on the playlist) until the song starts playing next time..

Yes, but the plugin does not inform XMPlay that it has changed the file. For this to work XMPlay would have to support a custom interface (breaking WinAmp support) to allow it to be notified of file changes. XNplay normally scans files on initial addition to playlist (unless it is a playlis, in which case XMPlay assumes the titles in the playlist ae right) and on playback of each file.

And about the now-playing song's changed tag; perhaps it could update and refresh it on the list as soon as the song is finished? =)

Again, the plugin does the file modification, not XMPlay. So XMPlay would have to export a custom interface/function, or the plugin would have to wait until the file is free, write to the file, and then XMPlay would have to somehow detect the file change.

Sorry, but as a programmer I don't think it is workable.

[Jace]

Hmm..
Right-click a button and choose 'refresh song titles'?

[Josh]

Hmm, any chance for WinAmp style visualizations?

[Retro]

My suggestion:
Ability to write a pls/m3u file consisting of highlighted files. Could be done by right-clicking, perhaps.

My bug (?) report:
When adding a directory to playlist, XMPlay seems to verify those new files, although verify new files is disabled.

[guest]

XMPlay 2.6 doesn't display ID3v2 comment.

[Ian @ un4seen]

Regarding updating titles after editting tags... the next release will update the titles after editting tags

[Pike84]

Hmm.. Boggy made it all sound really difficult, but Winamp has had this feature for as long as I can recall . Anyway, nice thing it will be in Xmplay too .

[Torkell]

Hmm.. Boggy made it all sound really difficult, but Winamp has had this feature for as long as I can recall . Anyway, nice thing it will be in Xmplay too .

Sorry. I don't know everything, and I thought it *would* be really difficult as XMPlay does not currently ave a built-in tag editor. Never used Winamp, so I don't know how it does it (probably built-in tag editor)

Regarding updating titles after editting tags... the next release will update the titles after editting tags

Is it going to have a built-in tag editor, or will ituse some other method? I'm curious as to how you've done this one.

[Jace]

As far as I can see it, XMPlay uses exactly the same ID3-tag editor as WinAmp

[Irrational86]

The MP3 ID3 tag editor is NOT built in!!! XMPlay uses the in_mp3.dll plugin from winamp (winamp doesnt have it built in either) and the plugin is the one that allows the programs who use it to modify ID3 Tags

[Ian @ un4seen]

Is it going to have a built-in tag editor, or will ituse some other method? I'm curious as to how you've done this one.

The plugin's "file info" window is a modal dialog (control of the thread does not return to the app until the user closes the dialog), so XMPlay simply has to rescan the title from the file then.

I wasn't really thinking of tag editting possibilities when doing the plugin support, so never bothered to rescan the files previously

[elgenaro]

Hi, i (think i) found a bug:
If xmplay doesn't find a song, it will stay there, forever, waiting.

Ok, a feature i'd love is to scroll more than one item at a time using the mouse scroll, because it's kind of tiring to be scrolling down one song at a time, it'll take ages to get to the last item.

About equalizers and skins, xmplay could have a new window, added to the left, next to Output, Miscellaneous, Plugins, Device Setup, Integration, a new window, with a bigger equalizer, and there would be no problems with skins, it could take the same images as the ones that the actual equalizer has.


One last thing:
Better info in tooltips, 'cause i don't know what some means, just a little more informative, that's all.


!saludos (cheers) !
Genaro

[jackal1234]

I think xmplay should have the ability to crossfade between tracks. Another idea I had was to have a music library... and have it organize it by filetype and genre

[Sub-Zero]

Whoa, wait a minute...why do people want all of these features?  They're already in other players.  I don't want to see a bloated xmplay that plays videos and flashes lights all over the screen. Why? just about EVERY other player out there supports these 'features' (and they all use the same video codecs, so you can't tell me one is better than the other quality wise).  In terms of mp3/ogg/lossy compressed audio/video, 95% of the playback quality is determined by the ENcoder, not the decoder.  Any differences between winamp and xmplay you hear I'm willing to bet are in your head, your drivers, or in your program settings.

I thought xmplay was supposed to be THE module player for windows...After all, that's where it really excels.  Leave the video/mp3 stuff for other players.  All those other players are just shells for the existing codecs anyway.  Do we really need to make xmplay yet another shell?  Also, if you want to use winamp plugins, just use winamp.  Xmplay or anything else won't sound any different or offer any other functionality.  I don't see what the big deal is with having both on the hd.  They're less than a MB each..

I would like to see an expansion of supported module formats, like .669, .nst, .mdl, .okt (and others) , before seeing things like video playback, pretty skins or screensavers.  After all, MOD files are what xmplay is about right?  How about at least prelim support for sk@le tracker, MT2(with .mtx exts?) and Renoise?  I realize those are difficult formats to implement and it would take awhile, but I'd rather see efforts go in that direction than towards features that already exist in every other player out there.

Ian, I see you're defending the skins a lot when some feature like a bigger EQ with more bands, or extra interpolation settings (both good ideas IMHO!), would require a change.  Think about it, do you really want to hinder development of xmplay because of a skin?  Is that the most important thing about xmplay?  I don't know, but skins are pretty much at the bottom of my list.  I use it because its got the best module playback routine on windows that I can find anywhere.  I know, I know, its your project, but I think I've got a point here .  Anyway, just my $.02

Btw, on the EQ, I'd like to see a 31hz and 20khz slider added.  I really think that's all it needs .

[Ian @ un4seen]

Ian, I see you're defending the skins a lot when some feature like a bigger EQ with more bands, or extra interpolation settings (both good ideas IMHO!), would require a change.  Think about it, do you really want to hinder development of xmplay because of a skin?  Is that the most important thing about xmplay?

Nope, skins are certainly not the main priority. If an important new feature requires a skin modification, then so be it - for example, the global hotkeys.

But I will try to avoid skin modifications when possible (eg. put new options in a right-click menu), simply because it makes sense to do so

[Ralesk]

Therefore, I guess, it'd be a good idea for XMP3.x for example to have most options (that you might only rarely need, for example) in a unskinned separate window or invent some sort of flexible skinning with fonts and text usable in them (like in XMPlay 1.x, there the text changed if I set antialiasing )

I hope I'm making sense.

[Arjan]

What i would like to see is just this one thing.

That xmplay not only remembers the playlist or the file that was playing last.. but also the position.
The reason i ask for this is  because i play alot of big Mix mp3 files with mixes of sometimes 70 minutes of more.
it would be cool that if lets say . i stop xmplay when the mp3 file was at 10 minutes and 30 seconds . the next tim ei start up xmplay it continues playing that mp3 file at that point.

Thats all i'm asking for.. because this player is just perfect for me in every other way.

Many thanks for the people that make it.


MightyD

[Pike84]

Sub-Zero, you got a point there - I don't want to see Xmplay bloated either. But I still think music formats (at least as common as mp3 for instance) should be supported. You must face it: Xmplay already is a lot more than just a mod player, and it's not going back either.

Video files and that sort of stuff should certainly be left out. There's no point in supporting them, when there are so many dedicated programs around. Still, now that Xmplay has proceeded so far into being the ultimate music player, then why hold back?

It may not be very difficult using many programs for different file types, but why make things complicated rather than simple? Besides, think of some people less qualified in using computers; it's much easier for that kinda folks, if they don't need to get many players to fiddle with (or for anyone, really).

So, I think Xmplay should be developed further, but in the way of music files, not all media files. Xmplay can have lotsa new features before there's a hint of it being bloated - it's under 250 kb at the moment, which is pretty incredible, it already being the best music player around