6 ms·

Just noticed this reply, possibly the most eloquent way anyone has ever told me that they think I'm a moron. Yes, I've read Worse is Better. No, I don't think t

Just noticed this reply, possibly the most eloquent way anyone has ever told me that they think I'm a moron. Yes, I've read Worse is Better. No, I don't think that the Unix philosophy is always the right one. I was 100% serious, though, no satire. On the contrary, I'm the one having a hard time believing the things people complained about in this thread. I mean, seriously? Make a new playlist and drag and drop the song into it vs. right click the song and hit "add to queue." I simply cannot believe that this is the kind of thing that would be a deal breaker for someone. If I may be so trite, it is a "first world problem" if ever there was one. "This program is perfect except for one minor detail; I don't care if there's a baby in it, this bathwater needs to be gone yesterday." One thing we might be able to agree on is the value of providing simple building blocks and a powerful but easy to use scripting interface. I think we could both learn to love the child of emacs and foobar, that would let you happily do whatever silly things you want to do with your queues while I remain none the wiser. In closing, to echo your passive aggressive tone, have heard this quote by Alan J. Perlis? "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Perhaps the same could be said about programs that expose many different and separate interfaces for fundamentally similar problems.

aaronem 13y ago
A fair response, although I might quibble with your choice of the term "moron"; if that was what I thought, I doubt I'd have bothered replying to you at all. (I note also that, in my earlier reply, I forgot to mention that several Foobar2000 users have requested better self-signed cert support from Pawlowski, whom I've never seen to respond favorably to such a request. I saw little value in registering for the HydrogenAudio forums, solely in order to weigh in on the side of a feature which the developer plainly doesn't consider worth his while to add.) I've never seen a playback queue as anything other than possibly an imperfect workaround for the limitations imposed by the inability of playlists to contain nodes pointing to other playlists, and my frustration around the subject of Foobar's playback queue stems from the fact that it's not even any good at that, much less at being a good idea in its own right -- the fact that the queue's contents aren't even exposed in the UI without adding a plugin should, I concede, have served as a strong clue. (And your choice of Perlis' epigram strikes me as truly inspired! Why, indeed, should we have these two things, the playlist and the playback queue, which behave similarly but not identically, and whose coexistence requires a bunch of otherwise unnecessary special cases?) I can appreciate your incredulity at playback queue (mis)behavior being a deal-breaker for anyone with foobar2000; annoying as I find those idiosyncrasies, they don't rise to that level. The brokenness around self-signed SSL certs does, though, because it makes the player effectively unusable for my purposes anywhere but at home -- hardly, I think, something which qualifies my abandonment of foobar2000 for streaming use as "throwing the baby out with the bathwater". It's funny you should mention "the child of Emacs and foobar"; as it happens, there is a music-player integration package [1] for Emacs, which I've occasionally considered trying out since that is the editor I use. Unfortunately, EMMS doesn't appear to support FLAC/CUE-per-album, which I regard as a sine qua non since so much of my library is in that format. Given the increasingly solid multimedia support in modern browsers, and given also the existence of a pure-Javascript FLAC decoding library [2] which has worked surprisingly nicely in my trials, I've lately been mulling over the thought of writing my own relatively simple-minded player, which I could host in the same place as my music library and just fire up in a browser when I wanted to use it -- and which, yes, would support adding playlists to playlists, and be able to shuffle among playlist nodes in a sensible way. By succeeding in such an effort, I could both satisfy my own desire for a particular combination of features, and make a very convincing public argument for my belief that the current style of user interaction around music playlists is neither the last nor the best word on the matter. On that note, I appreciate your taking the time to argue with me in this thread; any opportunity to refine my thinking, on any subject, is of value. [1]: https://www.gnu.org/software/emms/ https://www.gnu.org/software/emms/ [2]: http://badassjs.com/post/25174050115/flac-js-aurora-and-the-future-of-web-audio http://badassjs.com/post/25174050115/flac-js-aurora-and-the-...

aaronem 13y ago

A fair response, although I might quibble with your choice of the term "moron"; if that was what I thought, I doubt I'd have bothered replying to you at all. (I note also that, in my earlier reply, I forgot to mention that several Foobar2000 users have requested better self-signed cert support from Pawlowski, whom I've never seen to respond favorably to such a request. I saw little value in registering for the HydrogenAudio forums, solely in order to weigh in on the side of a feature which the developer plainly doesn't consider worth his while to add.) I've never seen a playback queue as anything other than possibly an imperfect workaround for the limitations imposed by the inability of playlists to contain nodes pointing to other playlists, and my frustration around the subject of Foobar's playback queue stems from the fact that it's not even any good at that, much less at being a good idea in its own right -- the fact that the queue's contents aren't even exposed in the UI without adding a plugin should, I concede, have served as a strong clue. (And your choice of Perlis' epigram strikes me as truly inspired! Why, indeed, should we have these two things, the playlist and the playback queue, which behave similarly but not identically, and whose coexistence requires a bunch of otherwise unnecessary special cases?) I can appreciate your incredulity at playback queue (mis)behavior being a deal-breaker for anyone with foobar2000; annoying as I find those idiosyncrasies, they don't rise to that level. The brokenness around self-signed SSL certs does, though, because it makes the player effectively unusable for my purposes anywhere but at home -- hardly, I think, something which qualifies my abandonment of foobar2000 for streaming use as "throwing the baby out with the bathwater". It's funny you should mention "the child of Emacs and foobar"; as it happens, there is a music-player integration package [1] for Emacs, which I've occasionally considered trying out since that is the editor I use. Unfortunately, EMMS doesn't appear to support FLAC/CUE-per-album, which I regard as a sine qua non since so much of my library is in that format. Given the increasingly solid multimedia support in modern browsers, and given also the existence of a pure-Javascript FLAC decoding library [2] which has worked surprisingly nicely in my trials, I've lately been mulling over the thought of writing my own relatively simple-minded player, which I could host in the same place as my music library and just fire up in a browser when I wanted to use it -- and which, yes, would support adding playlists to playlists, and be able to shuffle among playlist nodes in a sensible way. By succeeding in such an effort, I could both satisfy my own desire for a particular combination of features, and make a very convincing public argument for my belief that the current style of user interaction around music playlists is neither the last nor the best word on the matter. On that note, I appreciate your taking the time to argue with me in this thread; any opportunity to refine my thinking, on any subject, is of value. [1]: https://www.gnu.org/software/emms/ https://www.gnu.org/software/emms/ [2]: http://badassjs.com/post/25174050115/flac-js-aurora-and-the-future-of-web-audio http://badassjs.com/post/25174050115/flac-js-aurora-and-the-...