Re: [Musicpd-dev-team] Support for parsing/tagging flac files according to embedded cuesheets
On 2009/03/24 10:10, Max Kellermann m...@duempel.org wrote: Do you want a git repository for that? Is there a public svn repository, which we could import to get the full code history into git? Found it, and cloned: http://git.musicpd.org/cgit/mirror/cuetools.git/ Maybe we should ask if Svend has abandoned the project, in this case you could take over the whole project, and just change the build scripts to generate an additional shared library with a well-defined and stable API. Max -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] couple client-related questions
On Tue, Mar 24, 2009 at 4:45 PM, Max Kellermann m...@duempel.org wrote: In this case, is there any point in using getopt? Yes, maybe to get the binary size down on systems which support it. Might be interesting for tiny embedded systems. For now, I'd say just extend the current integrated option parser. We might later add a compile-time option for using getopt_long() instead if available, for those users who think saving a few bytes is useful. Ok, I'll throw the getopt_long code on a branch on my public repository and work on builtin for now. From ncmpc's recent visual selection addition, I noticed that moving a large block of songs is quite slow because it has to send a command for every song in the block. Romain's implementation wasn't well optimized. To move a whole block one up or down, it's enough to move just one single song: e.g. to move 4:8 to 3, simply send move 3 7. This is what I was initially going to do, but the command actually sends swapid instead of move. I meant to ask about this, but got distracted as I started working on the mpd side. So is it reasonable to just have ncmpc use moveid, or should it still use swapid if not moving a range? I'll get the move range command properly implemented eventually too - not totally trivial because of error checking (it'd be the first command which has an argument which could either be a range or an integer, I think). Busy week, though, then going out of town (camping, no computers!) for a week so don't get your hopes up too much! Jeffrey -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] couple client-related questions
On 2009/03/24 22:55, Jeffrey Middleton jefr...@gmail.com wrote: This is what I was initially going to do, but the command actually sends swapid instead of move. I meant to ask about this, but got distracted as I started working on the mpd side. So is it reasonable to just have ncmpc use moveid, or should it still use swapid if not moving a range? Both commands do the job, so I don't care much. It's just obvious to make single move just a special case of range move, i.e. use the same comand for both (and share the same code). I'll get the move range command properly implemented eventually too - not totally trivial because of error checking (it'd be the first command which has an argument which could either be a range or an integer, I think). Busy week, though, then going out of town (camping, no computers!) for a week so don't get your hopes up too much! There's already playlistinfo. I think that range feature isn't documented yet. Documentation patch welcome. Max -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team