Re: [Musicpd-dev-team] Other features for mpc
I'm not too sure about the globbing question at first glance. However, refining ambiguous completion seems a prime candidate for placing inside mpc. If you filter afterwards with a script, you're wasting time querying for information you then waste time throwing away, while mpc could easily just only list the necessary directories then exit. Jeffrey -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] S24_3LE output?
Can mpd be made to output S24_3LE? No, not without a patch. What format does mpd output? - Grant Demian mentioned that mpd outputs in a 32-bit format. I'm wondering if 16-bit audio converted to 32-bit by mpd, and then converted to S24_3LE by ALSA would end up adding noise? I brought this up on the ALSA list and they basically said it depends on how mpd converts to 32-bit. It depends on how the bits are added. Usually the bits added are low order bits-- this is to ensure that roundoff error does not keep adding noise to the system, and to use a common calculational track no matter wha the input, and so they use a size that is bigger then any possible. On the other hand they may want extra headroom and add the padding at the high end instead. Can anyone here shed any light on how mpd does this, and whether or not 16-32-24 would add noise in this case? - Grant -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Other features for mpc
On 2010/01/05 17:46, Jeff Frasca phaed...@u.washington.edu wrote: When done in the completer code, it requires two extra fork()/exec()s of the sed and sort code. The sed and sort code are more general than we would write, but they are also already debugged, and not that much more overhead for something that runs no more than once or twice in a second, and then only occasionally. mpc used to have (or still has? I'm not sure) special commands for the bash completion. That should be avoided if possible, because mpc shouldn't be bloated with interactive features. mpc isn't supposed to be an interactive client, and I think bash+sed (as you said) might be well enough for implementing the completion. If something is really missing in mpc, and you come to the conclusion that the completion can be optimized with a new mpc command, then this command should be designed in a generic way (if possible), to make it reusable for other mpc users. Note that I don't use the completion code, I don't have an oponion on that. I'll merge patches from folks who do use it and like to care about the code. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Patches for cuesheet support
2010/1/4 Max Kellermann m...@duempel.org: On 2010/01/03 15:05, Jon Heier snakeb...@jvnv.net wrote: When I issue mpc load filename.cue, I get this from mpd (running with --no-daemon --stdout --stderr -v) without the first patch: None of these are MPD error messages, so I guess libcue is misbehaving and writes to stderr (which a library shouldn't do, ever). I guess fixing libcue is the proper solution here (so that is returns NULL or otherwise properly indicates an error), unless you want to use the patch as a workaround. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Other features for mpc
On Tue, Jan 5, 2010 at 11:57 AM, Max Kellermann m...@duempel.org wrote: On 2010/01/05 17:46, Jeff Frasca phaed...@u.washington.edu wrote: When done in the completer code, it requires two extra fork()/exec()s of the sed and sort code. The sed and sort code are more general than we would write, but they are also already debugged, and not that much more overhead for something that runs no more than once or twice in a second, and then only occasionally. mpc used to have (or still has? I'm not sure) special commands for the bash completion. That should be avoided if possible, because mpc shouldn't be bloated with interactive features. mpc isn't supposed to be an interactive client, and I think bash+sed (as you said) might be well enough for implementing the completion. It still does have a tab and lstab command. For a short-term solution, it sounds like the currently implemented 'tab' command could be modified. Currently, it lists everything, then sees if each individual thing is a match to the given partial name. It could instead list the dirname of the partial name and check for matches to the basename of the partial name. This wouldn't add a ton of bloat, it seems. For long-term... Clearly Jeff uses mpc as an interactive client, and I do as well sometimes; we're probably not the only ones. Mpc is really quite close to an ideal command-line interactive client already, so what's the best approach for adding any desired interactive features? It's not just an additional few commands - stuff like the globbing mentioned earlier would modify existing commands. Jeffrey -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Other features for mpc
On Tue, 5 Jan 2010, Max Kellermann wrote: On 2010/01/05 17:46, Jeff Frasca phaed...@u.washington.edu wrote: When done in the completer code, it requires two extra fork()/exec()s of the sed and sort code. The sed and sort code are more general than we would write, but they are also already debugged, and not that much more overhead for something that runs no more than once or twice in a second, and then only occasionally. mpc used to have (or still has? I'm not sure) special commands for Still has. 'mpc tab' is the interesting one here (used to complete 'mpc add'). the bash completion. That should be avoided if possible, because mpc shouldn't be bloated with interactive features. mpc isn't supposed to be an interactive client, and I think bash+sed (as you said) might be well enough for implementing the completion. mpc is my main client. However, I agree on the minimalist approach to the code (that's why I like it). So, right now, cmd_tab() sends the listall command like this: if (!mpd_send_list_all(conn, )) printErrorAndExit(conn); The is the directory to list, so this could be made significantly smarter by supplying the directory. It took me 11 LoC (counting blank lines and closing brackets). It doesn't change the behavior with the current completer code--the items that get culled by the server would have been culled by the client. However, that change merely cuts down the traffic over the socket for subsequent tab mashes. Any tab mash in the top-level directory is just as expensive as before. It also doesn't get me what I want (list only the entries in the current directory level). That would require significantly more C code or the extra bash+sed that I'm already using. If something is really missing in mpc, and you come to the conclusion that the completion can be optimized with a new mpc command, then this command should be designed in a generic way (if possible), to make it reusable for other mpc users. Right. OTOH, my other feature idea--globbing or regex in 'mpc add' makes the command significantly more complex. I ended up writing a mockup of the functionality by adding an 'mpc radd' code (so mpc add continues to work exactly as before--thus not breaking any scripts). 'mpc radd' is more of an interactive type feature, but I know at least one other person on the list wants it. (All the code is still sitting on my harddrive, I haven't pushed any of it yet.) Jeff -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Other features for mpc
On 2010/01/05 19:51, Jeff Frasca phaed...@u.washington.edu wrote: However, that change merely cuts down the traffic over the socket for subsequent tab mashes. Any tab mash in the top-level directory is just as expensive as before. That's already a big improvement. It also doesn't get me what I want (list only the entries in the current directory level). That would require significantly more C code or the extra bash+sed that I'm already using. mpc ls foo/bar I've never understood why the completion code didn't use this very basic command. Right. OTOH, my other feature idea--globbing or regex in 'mpc add' makes the command significantly more complex. I ended up writing a mockup of the functionality by adding an 'mpc radd' code (so mpc add continues to work exactly as before--thus not breaking any scripts). 'mpc radd' is more of an interactive type feature, but I know at least one other person on the list wants it. Ok, let's say we add a compile-time option to disable interactive commands (like ncmpc's --enable-mini option?). Those on tiny embedded systems will have the choice. This would raise my personal limit for accepting bloaty mpc patches significantly. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Other features for mpc
On Tue, 5 Jan 2010, Max Kellermann wrote: src/command.c:943: error: initialization discards qualifiers from pointer target type Compile with --enable-werror, please. The code should be warning clean. Fixed. Same spot. Configuring with --enable-werror from now on. The tab command should be disabled with --enable-mini. It's unlikely to be useful on those tiny platforms. Will do. Jeff -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
