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: Frequent API breaks in foobar2000 (Read 5633 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Frequent API breaks in foobar2000

Thank you for the information, Yotsuya. I miss my bacon.



Ditto 

All these fucking SDK changes are a nightmare.  Winamp tried it once and look what happened (3.x), foobar seems happy to do it every few months.  The solution is not to build the 'best' SDK known to man, but to build a decent one and let people become familiar with it.  No?


Frequent API breaks in foobar2000

Reply #2
foobar seems happy to do it every few months.
In general, foobar2000 0.9.x can load all components for older 0.9.y versions (with the exception of the KS output component from 0.9 which do not work on 0.9.1 and newer). By the way, 0.8.3 had been stable for over two years while 0.9 was developed behind closed doors.

The solution is not to build the 'best' SDK known to man, but to build a decent one and let people become familiar with it.
The solution to what? foobar2000 improves when Peter improves, and sometimes this means breaking compatibility with old versions. These breaks are not done light-heartedly, but we don't let compatibility concerns stop progress forever either.

Last but not least, watch your language around here, even if you are frustrated.

Frequent API breaks in foobar2000

Reply #3
foobar seems happy to do it every few months.
In general, foobar2000 0.9.x can load all components for older 0.9.y versions (with the exception of the ASIO and KS output components from 0.9 which do not work on 0.9.1 and newer). By the way, 0.8.3 had been stable for over two years while 0.9 was developed behing closed doors.

The solution is not to build the 'best' SDK known to man, but to build a decent one and let people become familiar with it.
The solution to what?


To what I was posting and to what you were replying to.

You make some valid points, yes.  It's just a shame that there seems to be many great plugins slipping through the cracks.

Frequent API breaks in foobar2000

Reply #4
[deleted]

Frequent API breaks in foobar2000

Reply #5
The solution to what? foobar2000 improves when Peter improves, and sometimes this means breaking compatibility with old versions. These breaks are not done light-heartedly, but we don't let compatibility concerns stop progress forever either.


"Progress" does not automatically mean "breaking compatibility with old versions". Many projects, freeware and commercial, happily can and will do both. (Check Perl and its evolution, for example.)

Let's face it: maintaining backward compatibility is boring, unsexy and a lot of work to boot.

And it's clearly not necessary for pre-1.0 releases anyway. So why bother?

Frequent API breaks in foobar2000

Reply #6
"Progress" does not automatically mean "breaking compatibility with old versions".
Of course not, and compatibility is not broken every time a new feature is added, but it is quite hard to try a radically different approach and keep compatibility with old versions. As I understand it, foobar2000 started as a self-improvement effort, and it still has some traits of a research project. In a way, it actually is about finding the best possible audio player or audio player architecture (criteria by which to measure "best" are not discussed here).

Frequent API breaks in foobar2000

Reply #7
In a way, it actually is about finding the best possible audio player or audio player architecture (criteria by which to measure "best" are not discussed here).

Err... that's a rather foonny statement. How do you find the "best possible audio player" without "criteria by which to measure "best""? Seems like a contradiction.

Anyway, fb2k is too closed to allow most non-C++ programmers to actually explore the outer limits of audio player architecture. (Then again, most people simply want a half-decent player.)

Well, one thing: projects that are not open source tend to be not as good as they could be. Meaning that to realise its full potential I think that fb2k should at some point (not necessarily now) go OS.

Frequent API breaks in foobar2000

Reply #8
Quote
Well, one thing: projects that are not open source tend to be not as good as they could be.
hehe, funny thing is that foobar is the case for some people to not switch to *nix, where is a contradiction here ? 
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Frequent API breaks in foobar2000

Reply #9
Hey guys, I was only really blowing hot air when I posted this - I certainly didn't think it would merit it's own topic.

However, it's no real problem that it breaks compatibility, just a nuisance.  It happens way more often that any other program I have used, but it's still only around once a year (read: not much at all).

My point was really this: when these breaks happen we loose very good plug-ins each time because either the dev has forgotten about Foobar or moved on to something else.  Couple that to the lack of a main, categorised plug-in site and you've got a little problem.  It's ok for veterans like us who have time to scour the forum and request links to plug-ins/plug-in replacements but not for the newbie who has spent days configuring his Foobar, updated to 0.9x only to loose all his plug-ins and configuration.

I understand why breaking compatibility is done, and I'm sure it's not a light hearted decision, but it is still problematic for new users (and some times experienced users too).

[Edit]Does any one know when this will stop happening?  1.0 I assume, but I could be wrong[/Edit]

Frequent API breaks in foobar2000

Reply #10

In a way, it actually is about finding the best possible audio player or audio player architecture (criteria by which to measure "best" are not discussed here).

Err... that's a rather foonny statement. How do you find the "best possible audio player" without "criteria by which to measure "best""? Seems like a contradiction.
How do you arrive at the conclusion that they don't exist simply because I didn't name them here?

Anyway, fb2k is too closed to allow most non-C++ programmers to actually explore the outer limits of audio player architecture. (Then again, most people simply want a half-decent player.)
True, I'll readily admit that this exploration is mainly done by Peter with contributions from a rather small group of other people. Perhaps I should have made that clearer before. While we do look at requests on the forum, very few concrete suggestions come from that direction. Most people here are just users after all, and I don't hold that against them.

Well, one thing: projects that are not open source tend to be not as good as they could be. Meaning that to realise its full potential I think that fb2k should at some point (not necessarily now) go OS.
I value Peter's continued dedication to fixing problems higher than a possibly heightened feature adoption rate, so the current approach is fine with me. I am personnally disappointed in the few so-called "foobar2000 clones" out there, because they rarely mimick more than the look of the default user interface, while the component architecture is what truly separates foobar2000 from other players.

Frequent API breaks in foobar2000

Reply #11
Anyway, fb2k is too closed to allow most non-C++ programmers to actually explore the outer limits of audio player architecture. (Then again, most people simply want a half-decent player.)
True, I'll readily admit that this exploration is mainly done by Peter with contributions from a rather small group of other people. Perhaps I should have made that clearer before. While we do look at requests on the forum, very few concrete suggestions come from that direction. Most people here are just users after all, and I don't hold that against them.

Yeah, thanks for pointing that out, mouthwatering

Phew, it's a royal PITA trying to write an all-encompassing wrapper for foobar2000's API  ... so I dropped it. Just going to focus on wrapping the API's that I deem necessary for whatever plugin in progress...

... then comes a question: Will a plugin created in such way (i.e. uses a wrapper to allow non-C++ languages to access fb2k's API) considered acceptable by foobar2000 community (i.e. may be publicly plugged)? I did recall some plugins taken off public fb2k space because it does not conform to some guidelines...

Another question, slightly OT, is it allowed to create a DirectX-driving plugin to produce fullscreen AVS?

Edit: FYI, I'm trying to make some visualizer plugins for foobar2000 using FreePascal.

Frequent API breaks in foobar2000

Reply #12
In a way, it actually is about finding the best possible audio player or audio player architecture (criteria by which to measure "best" are not discussed here).

Err... that's a rather foonny statement. How do you find the "best possible audio player" without "criteria by which to measure "best""? Seems like a contradiction.
How do you arrive at the conclusion that they don't exist simply because I didn't name them here?
Are they under wraps? I have not seen many attempts hereabouts to define "best" or criteria for "best".

And for a very good reason: there's only one person in the world who knows what is the best player for me and that's me. As there's only one person in the world who knows what is the best player for you and that's you.

It is my firm conviction that fb2k could do more (it already does a lot: it's my favourite player after all) to allow people to tweak things w/o having to write their own plugins.

Well, one thing: projects that are not open source tend to be not as good as they could be. Meaning that to realise its full potential I think that fb2k should at some point (not necessarily now) go OS.
I value Peter's continued dedication to fixing problems higher than a possibly heightened feature adoption rate, so the current approach is fine with me. I am personnally disappointed in the few so-called "foobar2000 clones" out there, because they rarely mimick more than the look of the default user interface, while the component architecture is what truly separates foobar2000 from other players.
I would agree with the last sentence if writing a plugin wouldn't be so damn hard. I am pretty good at C and good enough at C++ to work on existing code. Still, the fb2k SDK leaves me with the same sinking feeling I experienced almost two decades ago when I was perusing the first Windows SDK.

Yeah, the fb2k SDK really looks like something that crawled out of a Microsoft SDK committee meeting

 

Frequent API breaks in foobar2000

Reply #13
[deleted]