Shortly after musync became practically usable, however, udoprog started hacking on it, and the current version is only loosely related to my old code (that was, for all I know, lost — for the better I believe). My current role in musync’s development is more or less reduced to finding bugs and hammering udo on IRC until he fixes them.

So, what musync does is it takes a number of music files (or folders if running in recursive mode) runs a specified command to add them to the file/folder structure according to a given rule, optionally filtering and/or replacing non-wanted characters in the process. The file-folder structure may for example be »artist/album/NN-title.ext«, and the add command could be simply copying the files.

But starting with recent musync versions, commands are Python lambda expressions, and can thus mean running several commands in sequence per file; I, for example, have my add command set to both copying the files to their calculated targets and then telling xmms2, my music player, to add them to its database. Here’s a code snippet for the relevant parts of musync.conf:

[site]
root:           "/var/storage/Musik"
xmms2_sync_lib: lambda file: m.execute("/usr/bin/nyxmms2", "server", "import", file)
add:            lambda src, dest: (sh.copy(src, dest), xmms2_sync_lib(dest))

To add newly ripped or downloaded music to my collection with musync, all I now need to do is running musync -c site add <files or directories>.

Other uses would include transferring music files (or directories) to a music player, optionally transcoding them to a format of choice in the process  (I keep my collection mostly in FLAC but transcode it to vorbis to save space when I put it on my DAP), maintaining multiple different directory structures of the same music files using (symbolic-) links or making a »shadow root« with sorted symbolic links to unsorted originals still left in the downloads/incoming directory.