Author Topic: XMPlay 2.7 suggestions  (Read 83627 times)

deus-ex

  • Posts: 235
Re: XMPlay 2.7 suggestions
« Reply #50 on: 2 Mar '03 - 13:55 »
2Sub-Zero

hey, are you the one, who wrote the excellent Adlib Tracker II? ;D

if so, how about writing a plugin for your .a2m-format, including support for the .a2m-macros,
or maybe providing sources to ian to implement native support - that would really be cool 8)

Fraggie

  • Posts: 710
Re: XMPlay 2.7 suggestions
« Reply #51 on: 2 Mar '03 - 20:40 »
Quote

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.

I agree. Ian, how about a PolyTracker (*.ptm) loader? There are lots of such modules (certainly much more than MTM's :)), and the file format itself is just a "remixed" S3M.

HyperDrive

  • Posts: 20
Re: XMPlay 2.7 suggestions
« Reply #52 on: 3 Mar '03 - 00:13 »
I believe new module loaders and higher (studio+) quality resampling/mixing routines should be top priority. I mean, don't we have enough PCM/bitstream players?! Do you REALLY need another bloated piece of (compiled) code?!
Also, for practical purposes, I don't see any reason why a player should have a skinning system. Eye candy? Come on, people! I'm sure you have something better to do than to sit all day changing skins! Load a playlist, minimise that thing and go do something useful! (Some coding, for example! ;D)
Development focus must shift towards improving what made XMPlay famous in the first place... Let's make it THE BEST module player, not another average generic player. Besides, being a software developer, you (should! ;)) know how "featuritis" can be a deadly disease!

Torkell

  • Posts: 1169
Re: XMPlay 2.7 suggestions
« Reply #53 on: 3 Mar '03 - 17:55 »
Quote

I believe new module loaders and higher (studio+) quality resampling/mixing routines should be top priority. I mean, don't we have enough PCM/bitstream players?! Do you REALLY need another bloated piece of (compiled) code?!

Yes, I agree a bit, but almost everyone has a feature they want which isn't in any player or is only in one.
Quote

Also, for practical purposes, I don't see any reason why a player should have a skinning system. Eye candy? Come on, people! I'm sure you have something better to do than to sit all day changing skins!

Nope. Unless playing Quake counts 8)
Quote

Load a playlist, minimise that thing and go do something useful! (Some coding, for example! ;D)

The ability to read messages on a forum does not require or confer coding skills.
Quote

Development focus must shift towards improving what made XMPlay famous in the first place... Let's make it THE BEST module player, not another average generic player.

It started off as a great module player. It still is. However, it is kinda useful to have a unified module & stream player. Especially when your playlist has everything from .FT to .WAV (including .IT, .MOD, .OGG, .MP3, .S3M, .UMX and a few others :))
Quote

Besides, being a software developer, you (should! ;)) know how "featuritis" can be a deadly disease!

It can be, but a *lot* of features are supplied by third-party seperatly available modules (plugins, skins, ...). Also, considering the original version (1.7) was around 120kB, and the current (2.6) is more like 230kB (I think), I don't think "featuritis" will be a problem for some time.

Sub-Zero

  • Posts: 49
Re: XMPlay 2.7 suggestions
« Reply #54 on: 3 Mar '03 - 21:21 »
Ian,
hehe ok.  That's good.  I guess I got the wrong impression from reading some of your other posts.


Kynes,

Well, I believe that there needs to be a balance of features vs simplicity.  If you have too many features, you alienate users, and if you have too few, you alienate as well.  I'm fairly happy with the featureset of xmplay, but I still think there's room for improvement :) (that's a good thing btw).

While there may be people out there who are 'less qualified' users, that doesn't mean they shouldn't be stretched a bit now and then.  We can't just dumb everything down to their level all the time.  Its not like they'll be confused by two extra sliders on the EQ, or a few extra resample settings.  Its not like the player won't work if you don't understand what they are.  That's what default settings are for :).

Dirk,
No, I'm not.  I wish I was a good enough coder to write something like that, though.  The closest I get is playing around with the q2 source, haha.

Hyperdrive,
Cool to see you share my views :).  While relative binary size doesn't mean much to me (except in those cool demoscene contests), I do appreciate fast, well-written code.

BoggyB,

While supporting additional stream formats sounds nice, it kind of pollutes the purpose of the player.  As it is, I still have to use modplug (or the original tracker software) for some formats because xmplay doesn't support them.  In XMplay, I think this should take priority over stream formats.  Let those be supported by plugins as you say.  But the core ideology of the player should be built-in as much as possible :).  In the case of XMplay, that would be modules (right?).  Again, just my opinion.

deus-ex

  • Posts: 235
Re: XMPlay 2.7 suggestions
« Reply #55 on: 3 Mar '03 - 22:08 »
2Sub-Zero
bad luck. for me, that is. ;D
playing around with q2 source is'nt that bad, though. :laugh:


2Fraggie
2Sub-Zero

i do have support for most of your requested formats since quiet a long time now,
using a hard to find winamp-plugin, which is derived from the good old open cubic player. ;)
it's called in_ims.dll and supports mod, xm, it, mxm, s3m, ams, dmf, dml, mtm, okt, ptm, ult .

xmplay overides native supported formats with its own engine of course.

Pike84

  • Posts: 1398
Re: XMPlay 2.7 suggestions
« Reply #56 on: 4 Mar '03 - 01:29 »
Quote

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

Oh, and I just remembered, it'd also be good to update the titles when adding tracks to the list, so that it would also load the tracklength (no need for that when loading a list tho).

Pike84

  • Posts: 1398
Re: XMPlay 2.7 suggestions
« Reply #57 on: 4 Mar '03 - 02:07 »
Quote

Well, I believe that there needs to be a balance of features vs simplicity.  If you have too many features, you alienate users, and if you have too few, you alienate as well.  I'm fairly happy with the featureset of xmplay, but I still think there's room for improvement :) (that's a good thing btw).

While there may be people out there who are 'less qualified' users, that doesn't mean they shouldn't be stretched a bit now and then.  We can't just dumb everything down to their level all the time.  Its not like they'll be confused by two extra sliders on the EQ, or a few extra resample settings.  Its not like the player won't work if you don't understand what they are.  That's what default settings are for :).

It's all sensible you're saying here, I agree. Still, I think using many programs for playing music is something to be overcome. IE, I think tweaking the players preferences once in a while is just fine, compared to having to use many players for my music. So I also think, supporting as many music formats as possible (in one way or another), is something to strive for. That isn't bloating the player either. Adding a video support would be another story tho.

Torkell

  • Posts: 1169
Re: XMPlay 2.7 suggestions
« Reply #58 on: 5 Mar '03 - 14:34 »
Quote

BoggyB,

While supporting additional stream formats sounds nice, it kind of pollutes the purpose of the player.

Point taken. Then again, it is kinda useful to be able to use one program for playing lots of different formats (my playlist is about 2/3 modules, 1/3 streams).
Quote

As it is, I still have to use modplug (or the original tracker software) for some formats because xmplay doesn't support them.

Have you tried looking for suitable plugins on http://support.xmplay.com?
Quote
In XMplay, I think this should take priority over stream formats.  Let those be supported by plugins as you say.  But the core ideology of the player should be built-in as much as possible :).  In the case of XMplay, that would be modules (right?).  Again, just my opinion.

I do agree a bit with your opinion, but I think that the stream formats would only have been added if there was a demand for them. If the users want streams, then let them have streams.
Besides, one audio player works very well for me.

Torkell

  • Posts: 1169
Re: XMPlay 2.7 suggestions
« Reply #59 on: 6 Mar '03 - 17:04 »
Anyone against stream formats should read these (taken from ogg and mp2,5:
Quote

just a question/request.  will it be possible to add support for these two formats to the player.  it remains my favourite, small fast and gas free (non bloated :) )

Quote

mpeg2.5 is already done for the next release, as well as layer 2 (mp2) and layer 1 (mp1) support :)

I've also already started on the OGG support, though it looks like it could bloat the thing to over 150K ;D ... once BASS 1.0 is released, which should be soon, I'll get back to finishing the OGG support for XMPlay.

Quote

Typical fanatic comment:
HOORAAY for Ian!
;) And I mean it. These features'll kick ass!

johnsonlam

  • Posts: 10
Re: XMPlay 2.7 suggestions
« Reply #60 on: 10 Mar '03 - 00:49 »
Quote

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.


Totally agree.

XMPlay should be a all-round module player, that's enough. If it can play MOD embedded in webpage, that's great! (I didn't mean it compete with MODPLUG).

But XMPLAY 2.6 was not very stable. Also when double cliking a file, XMPLAY start but not begin to play immediately ... something need to be done?

Torkell

  • Posts: 1169
Re: XMPlay 2.7 suggestions
« Reply #61 on: 10 Mar '03 - 18:22 »
Quote

Totally agree. [in reply to Sub-Zero - "Whoa, wait a minute...why do people want all of these features..."]

XMPlay should be a all-round module player, that's enough. If it can play MOD embedded in webpage, that's great! (I didn't mean it compete with MODPLUG).

It's weird seeing all this negative attitude to streams, considering that they were originally requested back in June 2001 (heading for two years ago) and that there was not a negative response at the time.
Quote

But XMPLAY 2.6 was not very stable. Also when double cliking a file, XMPLAY start but not begin to play immediately ... something need to be done?

Probably just loading the file... it can take some time to load big mod files, and MO3s are a bit slow because of decompressing.

By the way, why are people whinging about the stream support. It's been requested (ages ago), it's been added, it's been extended (e.g. internet stream support), and it's there to stay. There is rarely a good reason to remove a feature that works, that lots of people use, from a program. Even XMPlay started out as a module player, that doesn't mean that it has to stay as just a module player.

Sub-Zero

  • Posts: 49
Re: XMPlay 2.7 suggestions
« Reply #62 on: 10 Mar '03 - 20:40 »
Not looking to have it removed.  That's counter-productive. I just think the focus of the project should be on modules, while things like stream formats should be considered extras.  In any event, its Ian's project.  He can do whatever he wants.  This is just how I would like to see it progress.


Hakan

  • Posts: 26
Re: XMPlay 2.7 suggestions
« Reply #63 on: 11 Mar '03 - 07:54 »
I have a request that I'm not sure if it have been asked before. The ability to mute and solo channels in modules. It would be great when analysing tunes, especially with MO3's if you just want to listen to a channel (or a couple of them) and then could do it directly in XMPlay and not needing to UnMO3 the tune and load it in a tracker. Of course it is the awesome pattern view that makes this option interesting :)

Rah'Dick

  • XMPlay Support
  • Posts: 932
Re: XMPlay 2.7 suggestions
« Reply #64 on: 11 Mar '03 - 09:26 »
Yet another question about the Vis... What was the reason again why Ian didn't resize the vis window but stretches it...? Something about crashes I think...

[Edit] Ahh, found something:
Quote

At the moment, vis are only displayed in the single resolution, though it can be stretched :D ... Other resolutions (eg. fullscreen) are a possibility in future, but it's fairly low priority, so is unlikely to be in the next update.
[...]


Well. :P
[/Edit]
« Last Edit: 11 Mar '03 - 09:30 by RahDick »

guest

  • Guest
Re: XMPlay 2.7 suggestions
« Reply #65 on: 11 Mar '03 - 16:47 »
Playlist suggestion:

New option: "Automatically set already played track to be skipped".
So, when XMPlay is run next time, yet unplayed tracks are played first.

jackal1234

  • Posts: 2
Re: XMPlay 2.7 suggestions
« Reply #66 on: 12 Mar '03 - 20:58 »
Quote
New option: "Automatically set already played track to be skipped".
So, when XMPlay is run next time, yet unplayed tracks are played first.


yea I want this too.. in fact, I was going to hop on this topic and suggest this same feature. Another way you could do it is to have a mode where after it plays a song, it would delete that song from the playlist... so it would NEVER play it again in the same playlist that is.

Zarggg

  • Posts: 1242
Re: XMPlay 2.7 suggestions
« Reply #67 on: 12 Mar '03 - 22:13 »
I'd rather have Ian just tweak Random play. :laugh: ;D

Jace

  • Posts: 825
Re: XMPlay 2.7 suggestions
« Reply #68 on: 13 Mar '03 - 12:45 »
I have one little request.. That you could do the right-click-on-total-playlist-time and choose 'Get missing times' on the external playlist too.. :)
« Last Edit: 13 Mar '03 - 12:45 by Jacer »

Rah'Dick

  • XMPlay Support
  • Posts: 932
Re: XMPlay 2.7 suggestions
« Reply #69 on: 13 Mar '03 - 16:57 »
Seems like I found another little bug:
When you right-click the "-" Button on the small playlist and choose "Remove All", then you have to move the mouse over the playlist to make all entries vanish... Anyone else experiencing this?  ???

Zarggg

  • Posts: 1242
Re: XMPlay 2.7 suggestions
« Reply #70 on: 13 Mar '03 - 20:40 »
I've never noticed this.

Brightguy

  • Posts: 252
Re: XMPlay 2.7 suggestions
« Reply #71 on: 13 Mar '03 - 23:03 »
No, that's never happened to me either.

Irrational86

  • Posts: 960
Re: XMPlay 2.7 suggestions
« Reply #72 on: 14 Mar '03 - 02:01 »
Quote

Seems like I found another little bug:
When you right-click the "-" Button on the small playlist and choose "Remove All", then you have to move the mouse over the playlist to make all entries vanish... Anyone else experiencing this?  ???
Yup, i've had this bug happen to me. Its not a bug that you can just make happen whenever you want, it happens whenever IT wants. Just a few mins ago it happened, i think its due to a lot of resources being used at the time XMPlay is ran, or something like that...?

Zarggg

  • Posts: 1242
Suggestion for Shuffle
« Reply #73 on: 14 Mar '03 - 13:20 »
When one shuffles the playlist, could you make it so that it checks the first letter of the filename and makes sure that the next file in the shuffled list is not the same as the previous.  I store all my filenames as "Artist - Title.ext", and notice that I have large blocks (five or six songs) of the same artist.

Ian @ un4seen

  • Administrator
  • Posts: 20427
Re: XMPlay 2.7 suggestions
« Reply #74 on: 14 Mar '03 - 15:24 »
Quote
Also when double cliking a file, XMPLAY start but not begin to play immediately ... something need to be done?

If you've got the "LIST" option enabled ("Integration" panel), then make sure you've also got the "Play listed tracks" option enabled (right-click "LIST").

Quote
Well. :P

It's still low priority ;D

Quote

When one shuffles the playlist, could you make it so that it checks the first letter of the filename and makes sure that the next file in the shuffled list is not the same as the previous.  I store all my filenames as "Artist - Title.ext", and notice that I have large blocks (five or six songs) of the same artist.

Is that with the beta I sent you recently? The shuffle option was made faster in that version, but possibly less random. I've since changed it again, so that it's fast and random :)