Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: External control interface for foobar2000 (Read 34100 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

External control interface for foobar2000

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

External control interface for foobar2000

Reply #1 –
Quote
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.

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.
[a href="index.php?act=findpost&pid=253085"][{POST_SNAPBACK}][/a]

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.

External control interface for foobar2000

Reply #2 –
I wonder what you might be needing that can't be done through the command line controls...?
A riddle is a short sword attached to the next 2000 years.

External control interface for foobar2000

Reply #3 –
Quote
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.


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.

External control interface for foobar2000

Reply #4 –
Quote
I wonder what you might be needing that can't be done through the command line controls...?
[a href="index.php?act=findpost&pid=253167"][{POST_SNAPBACK}][/a]

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

External control interface for foobar2000

Reply #5 –
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.

External control interface for foobar2000

Reply #6 –
Quote
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.

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.

Quote
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.
[a href="index.php?act=findpost&pid=253254"][{POST_SNAPBACK}][/a]

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...

External control interface for foobar2000

Reply #7 –
Quote
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?
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.
Quote
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.
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.
Quote
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...[a href="index.php?act=findpost&pid=253263"][{POST_SNAPBACK}][/a]
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.

External control interface for foobar2000

Reply #8 –
Quote
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.

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.


Quote
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.

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.


Quote
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.

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.

External control interface for foobar2000

Reply #9 –
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.

External control interface for foobar2000

Reply #10 –
Quote
Foobar developers/users (and Peter  ) – are you interested in all this? [a href="index.php?act=findpost&pid=253469"][{POST_SNAPBACK}][/a]

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.

External control interface for foobar2000

Reply #11 –
Quote
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.

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


Quote
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.

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.

External control interface for foobar2000

Reply #12 –
Quote
The word "core" doesn't have a well defined meaning in software engineering world IMHO.[a href="index.php?act=findpost&pid=253674"][{POST_SNAPBACK}][/a]
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.

External control interface for foobar2000

Reply #13 –
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.

External control interface for foobar2000

Reply #14 –
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.

External control interface for foobar2000

Reply #15 –
Yes I would love to have a Konfabulator widget.
God Bless U.S.A

External control interface for foobar2000

Reply #16 –
what's the status of this?

External control interface for foobar2000

Reply #17 –
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.
Stay sane, exile.

External control interface for foobar2000

Reply #18 –
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).

External control interface for foobar2000

Reply #19 –
I am all with iostart and greenreaper. My current pet-project is a Jukebox which relies on remote-controlling a player. Currently it only runs on linux and I am deeply interested in making it run on Windows as well. That's why I am looking for a windows-based player with a well defined interface. So far I am not perfectly happy from what I found for Winamp, but to be honest, I did not yet fully research remote controlling Winamp.

On the other hand, I really prefer foobar2k over Winamp. So I was looking for a foobar interface and stumbled on this post. And I agree with most of what's being said so far.

Surely for the interface to be useful it should be included in the core functionality of foobar in some way. But I can sympathize with the fact that the current developers may have other points of interests or priorities. This is why I completely agree with henrym. Make it a community project, and once satisfied with the result, convince the package maintainers to get it packaged with the standard foobar distribution.

This way, pretty much everyone downloading foobar, will have it.

My mind is currently a bit in a disarray so I better stop here with my foolish ideas. However, I'd say, let's get an effort started. I'd say between iostart, greenreaper and me, we'll already have a small team going  Assuming that the two of you are interested. One thing though. I do not have a Windows development environment setup, which would certainly be useful for this. Neither do I have any experience with this. I'm coming from an all Java world, where all the tools are fairly straight-forward to set up.

External control interface for foobar2000

Reply #20 –
I'm currently also looking for a convenient way to control foobar2000 remotely and seamless.

I made a "mediaserver" in my home that should just playback music independently from any of my pc's. However, I have not found a decent way to control it properly.

I tried the http server. It has great potential, but the user interface is ugly, hard to customize, doesn't use ajax and has no way of searching. With some improvement it could be a good solution.

Wouldn't it be possible to have a component acting as a server or client and communicating with each other. The server could expose it's entire library, playlists, controls to the client. Maybe this could be an extension to the COM+ component?
Can't wait for a HD-AAC encoder :P
 

External control interface for foobar2000

Reply #21 –
Quote from: odyssey on
Wouldn't it be possible to have a component acting as a server or client and communicating with each other. The server could expose it's entire library, playlists, controls to the client. Maybe this could be an extension to the COM+ component?


foo_upnp in its latest version does just that. Access you collection/playlist remotely (not limited to the LAN but accessible from outside now) with optional transcoding to mp3, all within foobar.

External control interface for foobar2000

Reply #22 –
Quote from: bubbleguuum on
Quote from: odyssey on
Wouldn't it be possible to have a component acting as a server or client and communicating with each other. The server could expose it's entire library, playlists, controls to the client. Maybe this could be an extension to the COM+ component?


foo_upnp in its latest version does just that. Access you collection/playlist remotely (not limited to the LAN but accessible from outside now) with optional transcoding to mp3, all within foobar.

upnp is very useful in other situations, but not really in this one, since it's playing back at the *current* pc. What I would like to, is to control the foobar running on a "server" or htpc from any computer, that could be turned off if I don't use it anyway. Think of it like Citrix or Seamless Remote Desktop or foo_http.
Can't wait for a HD-AAC encoder :P

External control interface for foobar2000

Reply #23 –
I would be interested in exactly the same thing : a Client/Server foobar ! 
odyssey's idea is great. I've just thought about the same thing today, and that's how I've found this topic.
The idea would be to be able to run foobar in either Standard, Client or Server mode.
    * In
Standard mode (default), foobar would run just like it does today.
* In Server mode (optional), foobar would wait for remote keyboard/mouse commands from any authorized client (list of authorized IPs ?), execute those commands and return the results to all authorized clients.
* In Client mode (optional), foobar would need the IP of the PC where another foobar is installed in Server mode. Then foobar would send any keyboard/mouse command to the Server, wait for any returns from the Server and display them accordingly.[/li][/list]Please note that it's the Server that would actually play the music, using its own soundcard. The Client wouldn't play anything : it simply would tell the Server to do so.

Please note also that the Server could also have a GUI, which could be used for display purposes. Take a look at this example :
    *
Server : HTPC, nice "Hi-Fi looking" case, good soundcard, connected to the Hi-Fi amps and to a big LCD/plasma display
* Client : a Wi-Fi laptop, no soundcard needed of course
* Server GUI : display-oriented GUI, with Album Art Viewer, Spectrum, etc... so only the fancy stuff is displayed on the big plasma.
* Client GUI : search-oriented GUI, with Facets, Playlists, etc.[/li][/list]Imagine the possibilities ! 

I don't have any in-depth technical knowledge of foobar, so I don't know if a 3rd party component could actually achieve this, or if some core work from Peter & co. would be necessary. What do you think ?

Maybe this would deserve a separate topic ? "Feature request : Client/Server mode for foobar"

External control interface for foobar2000

Reply #24 –
That's a brilliant idea (much better explained than I did )

Although I'm not a dev (unfortunately), but at least we can outline the possebilities for 3rd part addons right now.

Existing components expect items to be availeble in the local library. That means that the library should contain all the remote files. This behavior is present in foo_upnp where it has implemented a protocol pointing to the files at the server (AFAIK). If the component is working in server-mode it would replicate the generated playlists from the client and possibly be able to playback the items with this protocol specified internally.

Although there is still a few problems that prevent such component from working seamless:

1. It's impossible to retrieve extended info from the library, such as which tags are available and the values for these. This is needed for filters, autoplaylists, search querys etc. (However, if this was implemented in the SDK, it would make foo_upnp be able to utilize library search features as well).

2. I'm wondering what would happen if you drag a local file onto a playlist that are supposed to contain remote files?

(Edit: Actually, when you think of it, it's pretty much foo_upnp behavior with an added layer that makes the server syncronice playlists with the client and respond to commands)
Can't wait for a HD-AAC encoder :P