next »

[Dynobot]

Otherwise XMPlay will remain Just Another Player amongst many for Windows.

No, it's already the best player you could imagine for module playback. ;P

Then perhaps XMplay et.al are happy with their niche.  If thats the case then maybe I am asking too much to want them to step out of their arena. 

[Dotpitch]

I hope you guys really consider making XMPlay a client/server based player. ... Even if you decide not to go with Linux [though I really hope you will] rest assured there are plenty of people waiting for a good client/server music player for any OS.   Esp. if it can be controlled via an iTouch or any wifi based remote.

I'm not really fond of the server-client-model in this case. It results in two executables, instead of the current tiny one. Also, you get all sorts of trouble with firewalls, limited user accounts and server-client communication errors. Granted, it'd be awesome to be able to control XMPlay from a different machine with a proper interface, but wouldn't a remote control plugin suffice for that?

[Dynobot]

I hope you guys really consider making XMPlay a client/server based player. ... Even if you decide not to go with Linux [though I really hope you will] rest assured there are plenty of people waiting for a good client/server music player for any OS.   Esp. if it can be controlled via an iTouch or any wifi based remote.

I'm not really fond of the server-client-model in this case. It results in two executables, instead of the current tiny one. Also, you get all sorts of trouble with firewalls, limited user accounts and server-client communication errors. Granted, it'd be awesome to be able to control XMPlay from a different machine with a proper interface, but wouldn't a remote control plugin suffice for that?

Obviously you have never tried Music Player Daemon...non of the issues you described.

But thats fine....I am totally happy with MPD and if no other music player wants to step up and compete thats fine with me.

Actually I have said my peace, made my points and presented my case.  That is all I wanted to do...the XM team can do what ever they want, and I don't blame them for following their user base.

I'm done here...this is my last post.

Just one example to show you how much you are falling behind...dBpoweramp just stepped up to the plate and already they are ahead of XMPlay with every feature an "Audiophile" could want.

dBpoweramp Renaissance is a revitalization of dAP (dBpoweramp Audio Player), re-built from the ground up with specific unique goals.

Designed to be the most efficient (in terms of memory footprint and resources used) audio player ever designed, featuring:

    * Built in UPnP Renderer: Renaissance enables your PC as a UPnP playback device, it can stream audio from a NAS / web for a distributed system where multiple playback devices can scattered around the home and playback from a single audio store, controlled by hand-held remotes, such as the iPod touch. (Renaissance appears as a UPnP Renderer, with Linn DS extensions)
    * Gapless playback: sample perfect decoding of mp3, Ogg and without saying any lossless format.
    * Bit perfect playback using WASAPI to bypass Windows mixer.
    * ReplayGain (not currently through UPnP)


Installation
http://www.dbpoweramp.com/developer-scripting-uplayer.htm

[Zarggg]

Rather than advertising Music Player Daemon, can we get back to the topic of feature suggestions?

(PS: One of the worst breeches of netiquette out there is to go to the forum for a certain program and say anything along the lines of "You should do <thing X> like <other software Y>". If people ask for clarification on a feature, it's fine to use other programs as examples, but XMPlay isn't Winamp, isn't Foobar, isn't etc...)

[Dotpitch]

I'm not really fond of the server-client-model in this case. It results in two executables, instead of the current tiny one. Also, you get all sorts of trouble with firewalls, limited user accounts and server-client communication errors. Granted, it'd be awesome to be able to control XMPlay from a different machine with a proper interface, but wouldn't a remote control plugin suffice for that?

Obviously you have never tried Music Player Daemon... non of the issues you described.

What a lousy counter-argument. Because you and I haven't encountered these issues with MPD on Linux doesn't mean an average user won't have them on a standard (or corporate) Windows machine.

I'm willing to drop the communication errors, but in exchange I ask you to answer the question whether a remote control plugin would be sufficient.

[Chinese Sausage]

Rather than advertising Music Player Daemon, can we get back to the topic of feature suggestions?

(PS: One of the worst breeches of netiquette out there is to go to the forum for a certain program and say anything along the lines of "You should do <thing X> like <other software Y>". If people ask for clarification on a feature, it's fine to use other programs as examples, but XMPlay isn't Winamp, isn't Foobar, isn't etc...)

+1

[Dynobot]

First off get it straight the MPD does not work in Windows it is for Linux.
Second the only way any user will have problems communicating with it from another machine or remote is IF either of them does not have an IP address.  
Third, there is ONLY one process running on the host [server] machine, which is the MPD server itself[period]...only ONE executable.  The server starts then binds to the IP of the host machine communicating via a port.

Going back and forth with point/counter-point about theoretical-hypothetical situations that simply do not happen it pointless and distracts from the issue.  I suppose you can pick any problem out of a hat and use it as a claim why MPD's methodology is not valid, no matter how off base and irrelevant the claim is, but if you do that why discuss anything at all?

The [purpose] of bringing up MPD in the first place was to show it as an example of how a good, lightweight and robust client/server model can be done.

I suggest to you and/or any of the developers of XM to first try MPD, and examine how it works, this will do away with a lot of ignorance and misguided perceptions.  It will also provide a good template in making your own client/server based music player....no need to re-invent the wheel.

As far as a plugin, sure that would work Foobar has a plugin for iTouch remote capabilities, this enables the standard remote for iTunes to control Foobar and alleviates the need to build a new remote for the iTouch.

[Dotpitch]

Second the only way any user will have problems communicating with it from another machine or remote is IF either of them does not have an IP address.

Most Windows machines have firewalls, which are the cause for my concern. Some users know how to configure them properly, a lot don't know and some are not allowed to. Which is quite different from the current state of XMPlay, where a vanilla XMPlay virtually always succeeds in playing music over the default device on first launch.

Third, there is ONLY one process running on the host [server] machine, which is the MPD server itself[period]...only ONE executable.  The server starts then binds to the IP of the host machine communicating via a port.

And to play music, you'll need a client with an interface. Basic music playback requires two executables, a server and a client, right?

As far as a plugin, sure that would work ...

Good .

[Dynobot]

Most Windows machines have firewalls, which are the cause for my concern. Some users know how to configure them properly, a lot don't know and some are not allowed to. Which is quite different from the current state of XMPlay, where a vanilla XMPlay virtually always succeeds in playing music over the default device on first launch.

In this case the client/server model will work much the same way a typical VNC application does.  A simple script during installation adds VNC to the exceptions list for Windows.  A similar script will alleviate any Firewall issues...this is the same for an iTouch remote for JRiver...no problems.

And to play music, you'll need a client with an interface. Basic music playback requires two executables, a server and a client, right?

Wrong...
The whole idea of client/server is to have different machines.  Most cases the server is a headless machine which only plays music.  When used as intended the server machine has one executable and the client machine will have one executable.  The only time there will be two processes running on one machine is if the user decides to use only one machine and brings up a front-end client on the server machine.  Furthermore, when a user logs in the server automatically starts and runs in the background so no need to execute the server manually.  In practice, on one machine a user will only execute one application, which is the client GUI.  So in either case one machine or two users need to only execute one application to play music.

[Cris]

Am I a little off, or I just don't understand the basic idea?

Aparat from a very few particular cases when you would really want such a client/server contraption, in real day-to-day life, which probably 99.9% of the users have, why exactly you need two different computers just to listen to music? Or, puttin it another way, why exactly would I want a music service/server on my system (+ another process for the GUI)?

Why exactly would anyone need music before logon, and who exactly cares if two users simulateneously logged on can listen to music using the same service? It's not like they can REALLY listen to music in the same time, because they wouldn't understand one bit of it. They will still have to listen separately.


Or, again, maybe I'm just to tired to udnerstand the simplicity of music playing?

[Dynobot]

Am I a little off, or I just don't understand the basic idea?


Or, again, maybe I'm just to tired to udnerstand the simplicity of music playing?

Have you ever heard of a contraption called a Squeezebox?

Well essentially its the same thing [works the same way]

Why would anyone want/need this....I don't know, I have one and use it all the time and so do plenty of other people apparently.

There are always those who see no need in a Squeezebox and opt to never buy one, thats their prerogative.  For people who are serious about their music, using a computer to surf the web, play music, do powerpoint etc. takes away from the potential of better sounding computer based music.  Baring in mind that these people probably have systems that are good enough to be able to pick up on small things in the front end.

Like I said before...it really makes no difference to me, I'm just expressing an idea.  Actually I think I am probably talking to the wrong audience.  

Being able to control a small headless computer has got to be the coolest thing.

http://sites.google.com/site/computeraudioorg/
 

[Cris]

Being able to control a small headless computer has got to be the coolest thing.

Maybe, but you see, as far as my experience goes with XMPlay, I can see that this player has nothing to do with being "the coolest thing". It just goes on what's practical (and which is, usually, totally opposite of "the coolest thing").

And no, I've never heard of Squeezebox.

The main idea is: I have a laptop. A simple no-so-fancy portable system that I use for work, school, relaxation. And, wherever I am, I use XMPlay to listen to music. Simple, fast, low resource usage (which, on portable systems, means longer battery life).

Now, if Ian were to cut down XMPlay in bits and pieces to transform it in a "huge" server/client software, then at the very least, the resource usage (both memory and CPU) will go up. You'd need a service in the system that is always on and which runs with the highest rights possible. If something goes wrong with it, it might be possible for the whole system to go down with it. This from the security point of view.
Next, as I said, higher resource usage (a service, a client process for GUI, communication between them, delays on high-system-usage, etc...) translates in lower battery life.
And next, with this kind of design, all the portability of XMPlay is gone. Many users around here (as far as I noticed) have XMPlay on a flash drive along with their music. They plug it in wherever they want (home, job, whatever) and BUM! they have music. With such a complicated design, they would have to waste at least 30 minutes of installation, configuration, etc... that is, if they have the necessary rights to install such software (because usually at your job you have a Limited account).
And next, if I understood it correctly, all this would work on network protocol. If so, Dotpitch made a very good point: what about firewalls? You said: "a basic script would solve that" (maybe in other words, but that was the idea). Well, wrong! Windows Firewall can be tricked with such scripts, which is why it's so vulnerable to malware. But 3rd party firewalls, with self defense and so on... those cannot be manipulated by external software. They have to be manually configured (either by dynamic interaction with the user, when the connection request is made, either by "simply" opening the firewall GUI and manually adding and editing a rule for it). Again, some might not have sufficient rights to do so and some might not know HOW to do so, especially if the server/client protocol is more complex and requires special ports and so on...


In my humble opinion, this kind of design is not worthed at the moment. If you really need it, then it appears that there are some alternatives that you like and that you can use. Or, as you with your own hands wrote, a simple plugin for XMPlay would suffice (you'll just have to find someone willing to code it).

[piovrauz]

I'ts monster cables faults. XMPlay is fine how it's now.

[Dotpitch]

It's monster cables faults.

You cannot generalize that one particular amateur experiment to apply to everything audiophile users would like to see implemented.

And to play music, you'll need a client with an interface. Basic music playback requires two executables, a server and a client, right?

Wrong ... When used as intended the server machine has one executable and the client machine will have one executable. ...  In practice, on one machine a user will only execute one application, which is the client GUI.

So there will be two executables in the main download, and the user will have to configure two executables. Obviously the server should always be running, that's one of the key ideas of a server-client-model, but it still has to be started.

For the rest, I agree with what Cris said (though he may have exaggerated the possible negative effects a bit ).

[Cris]

(though he may have exaggerated the possible negative effects a bit ).

Yeah... I tend to exaggerate a bit sometimes. 

[Jimmy Neutron]

Actually, Cris is quite right about the "portable" application users.

If the application is on a USB stick and taken to work, to the library, to a computer cafe, to a friend's house, or to a relative's house, it is unlikely that that the user will have administrative rights.

And in a lot of those places, the user won't have the ability to install anything or poke holes in the computer's firewall or make changes to the computer's registry or AV software.

I mean really, you want to install something on the computer that will allow you to remotely control it from another computer located somewhere else on the internet?  That sounds like the definition of malicious software to me.  I can see how that would make any system administrator shake in his boots.  And unless the program was open source, it would make any knowledgeable user worried about what else the program permitted in terms of control of the host computer by some script kiddie somewhere in the world.  Yeah, let's celebrate May Day and take control of thousands of computers!

No thanks, I'll keep my programs local, self-contained, and safe to run.

[Chinese Sausage]

It can be added as a plugin, as Dotpitch suggested. That way it won't interfere with XMPlay's originally intended integrity and portable capabilities.  

[Dynobot]

Being able to control a small headless computer has got to be the coolest thing.

Maybe, but you see, as far as my experience goes with XMPlay, I can see that this player has nothing to do with being "the coolest thing". It just goes on what's practical (and which is, usually, totally opposite of "the coolest thing").

And no, I've never heard of Squeezebox.

I see I am talking to the wrong type of people

My mistake. hahaha

[amit]

Is it possible to add in the saved setting  section an identification according to tag information or part of it . Maybe in the same syntax format as the quick search?

My thought is to attach different dsp/replaygain settings for different genres , but maybe other applications can be useful too.

[Zarggg]

I see I am talking to the wrong type of people

People around here generally want XMPlay to "just work", with no fuss or unnecessary setup.