Are there plans to add external control interface to foobar2000?

I am aware of the foo_remote/foo_winamp_spam plugins and of the command line interface. I believe, though, that automation should be a part of the core player, so applications that need to remotely control foobar2000 won't have to rely on 3rd party plugins or supply and install such plugins in the player.

Moreover, all the other major media players do have such interfaces built in.

Foobar2000 is a very powerful program, and I believe that everyone would benefit if this power was exposed to other applications by foobar2000 through a convenient interface.

I would love to hear your opinions on this.

Regards,
Alex
http://www.foxytunes.org

I don't agree that this needs to be implemented in the core. If people are prepared to install a browser extension (for example, like they do to use FoxyTunes), I don't see a problem in asking them to install a component for foobar as well. Also, that doesn't mean that they're going to have to do that for every single remote control app, since when someone actually does develop a decent remote control interface component, it won't take much to convince other developers to use it.

I wonder what you might be needing that can't be done through the command line controls...?

It's possible to ask the people to install a foobar component when they install another external application, but, IMHO, this solution is far from being elegant. Among other problems, the foobar component needs to be constantly updated to follow the player changes.

If foobar would export a nice interface to external applications from its core, the application wouldn't need to be aware of internal implementation/version changes in foobar – as long as the interface stays the same. This is the real point of having an "interface".

The way I see it, this is not unlike having a client-server architecture where foobar2000 is the server and the external application is the client. When looking at things this way it seems very strange that the server needs to be updated in any way when a new client is added.

You can say that the "server" functionality is not core foobar functionality, but this is exactly my point – it should be! IMHO, mature programs should allow other programs to control them – just look at COM, AppleScript, Bonobo, DCOP and other technologies. Their sole purpose is to allow programs to seamlessly interoperate without installing components into one another.

You can disagree with me, but this just seems like a serious omission from the otherwise powerful and great media player.

...Get all the tracks in the foobar2000 playlist that start with "foo" and do not end with "bar"....

This functionality can be implemented in a separate component, which means anybody is free to implement it however they think it should be done, and anybody else can implement their own version of the same thing.

Oh, and somebody can implement a subset of the iTunes for Windows interface to encourage certain developers who have added native iTunes bindings to their user-extensible applications.

But why would we want several versions of the same thing?
A standard media player interface for foobar could be easily defined, and wouldn't it better to have one, standard, foobar supported interface than a bunch of unrelated, unofficial components that expose slightly different interfaces? Also, third party components rely on their authors to be constantly updated (as opposed to official foobar components) and people tend to loose interest or not to have enough spare time to support their components for long periods of time.


IMHO, foobar interface can be designed with several existing similar interfaces in mind, like iTunes, WMP or JRiver MC. It can even be fully compatible with these interfaces (just look at the Mozilla ActiveX Control that is fully compatible with the Microsoft Browser component's interface).

My point is - this should be the official and the accepted foobar2000 interface.
I believe that we should be going towards standards and convergence and not the other way...

If it's so easy to define, please do. You are right of course that it would be good to create one "standard" interface, but I don't see why this couldn't be a third-party component, especially at first, if it becomes mature and a lot of people depend on it then it would be another story.Sure, and if Peter is interested in coding this that would be great of course, but you can hardly force him and it's not like it wouldn't take up his time.I don't think anyone would mind that, but there's still no reason to not make this into a separate component. If you think there is enough interest in this, please start a thread discussing how this should be done, or start yourself if you've got a good idea.

I'll gladly contribute to designing this interface if there is an initiative to actually implement it.

There are several issues here. First, we must discuss and choose a remoting technology – COM, Windows Messages, Sockets etc.
Then the actual interface should be defined. I believe that the SDK currently exposes many useful interfaces to the components – so the external interface can be a subset of these interfaces wrapped up for the external communication protocol.



Of course we cannot force Peter
It will surely take up some of his time, but I believe that this will really make his already great product much better. Also, this can be a community effort that will become "official" in the end and will be merged into the player core. I'm not familiar with foobar development methods, so I'm not sure this is possible.



This could be a separate component, but, like I said, IMHO it should be an official one shipped with foobar2000.

Foobar developers/users (and Peter ) – are you interested in all this?
If so, please post your comments here and maybe we'll start a new thread.

How about a community-made component? and ask Peter to have it ship with all versions of foobar2000.

This way any applications/components that depend on it (like FoxyTunes) can be fairly sure it's available, Peter doesn't necessarily have any more work to do, a nd users could remove it if they do not want/need it.

I can only speak for me, but I don't have a use for this, and thus very little motivation to work on it. However, that should not keep you and other interested people from continuing in this direction.

One other point: please distuingish (in speach) between the official distribution and the actual core which is just foobar2000.exe. At least a developer should be able to understand the difference.

This was the purpose of opening this discussion – to see whether there are people who are interested in this feature and are willing to work on it



The word "core" doesn't have a well defined meaning in software engineering world IMHO. For many programs the "core" is the main executable and the dozens dynamic libraries that come with it in the official distribution. When referring to the "core", I wasn't really talking about the file in which this feature is implemented. I meant "core functionality", meaning a feature that comes with the main program and is an essential part of it.

In the context of foobar2000, core (or rather the term "foobar2000 core") does have a clear meaning, and that's what I wanted to point out.

I would like to note that I am very interested in such functionality being available and distributed either as part of the "core" or as a standard addon module - just as long as it is likely to be "on" all the time (this seems like "core" to me, but I don't know enough about foobar2000 to say).

I am the current maintainer of a plugin for DesktopX called DXPlayer. Fortuitously, I have just written an article on the plugin, but basically DXPlayer is a "remote" for DesktopX objects. You click on an object, it clicks "play" in one of the players supported by DXPlayer that happen to be active, if there are any (either the first one on the list of players, or the player selected by the user). It allows changes and display of volume, position, title displays, etc. It makes it so that the user can use a DesktopX media player widget with whatever player they like . . . as long as that player is supported by DXPlayer. Here is an example of one of these widgets, which controls at least winamp/QCD (I forget iif support for iTunes and others was compiled into that one). DXPlayer uses both COM interfaces and windows messages to achieve this goal, whatever the player application requires.

Now, there is a user interest in Foobar2000 being added to that list of supported players, as you can see in the comments of the article above. To do this, I need to have some way of talking to Foobar2000. I was not aware of the foo_remote/foo_winamp_spam plugins, as I'm just looking into this now - I will consider them, but I would far prefer an internal implementation. It seems that there is none at this time, which makes me sad.

I do not really agree with the idea of each programmer having to install a plugin. It is partly a matter of ease of use/implementation on the client's end (my end), and partly of what is proper for me as a client program to do. In my opinon, a media player widget should not be messing around with people's installations of foobar2000. If I went around installing modules in IE to support my program, would people like that, or would it be viewed as spyware?

Having an interface available also means programmers who wants to access foobar2000 do not have to learn how to write a (potentially buggy) interface module. Who knows better what would be appropriate for such an interface and how to write it but the Foobar2000 community itself? Frankly, I have better things to do with my time, and would prefer to implement or improve support for those players that do have a well-defined interface, such as Winamp, WMP and iTunes. This is one good reason why those players are already available to control in DXPlayer.

So, yes, I would be very interested in such an interface, if available for the majority of Foobar2000 users - preferably all of them! I guess I could tell people to download a certain plugin, but in my opinion it would be better if it were included and "running" at all times without my intervention, if possible. This means developers can rely on it. If you are looking for which functions would be most used by an example client, I would suggest you download the free trial of DesktopX, and look at the Program Files\Stardock\Object Desktop\DesktopX\SDPlugins\DXPlayer.txt file, which contains a list of all the functions currently supported by DXPlayer.

Incidentally I wouldn't mind if you just went and implemented the Winamp interface as fully as possible, perhaps by improving the foo_winamp_spam or foo_remote plugins and including that as default. It would certainly save me and a lot of other program writers the need to add another interface to our applications - instantly you have compatability across the board! The best reference for the interface that I know of is the 5.04 updated SDK if you want to have a go at that.

I am going to agree with iosart and greenreaper in that I think this would be a great implementation to foobar2000. Unfortunately I wouldn't have any clue how to help with the project, but as a user of foobar2000 I think it would be great to extend its functionality to work with any of these widget applications that are becoming increasingly popular. Konfabulator, Kapsules, Avedesk, and Desktop X all have remotes for iTunes, and Desktop X has extended functionality to utilize Winamp, WMP and others.

Adding this to foobar2000 would allow end users, such as myself, to use tools like DXPlayer to make incredibly cool looking widgets that would run off foobar2000. I don't see how this could be anything but a boon to the program and the users.

Yes I would love to have a Konfabulator widget.

what's the status of this?

I'm a fan of evolution through usage. An interface that comes from pure design instead of evolving to fit usage will in my opinion not fit any user at all.
That being said, if the initial implementation is made in an extensible manner, it should be easy to enhance and expand it.
As an example, last night I wrote a component and a companion standalone executable to be able to seek in foobar2000 externally. It took a few hours tops, and most of that was digging around in MSDN docs on how to do named pipes properly. The resulting component and exe is just around 100 lines of code.

Well, we all have to agree with that, it would take a lot of time to design/develop/test this kind of interface. Anyway, I would like, if somebody will develop this interface (either Peter, or any developer) and Peter will include it in core or as official component (like foo_converter).