Managing parts in a digital music library?

[mgladdish]

A couple of groups I'm in manage their library online now. One big band in particular has all their parts as individual PDFs on Google Drive and lets everyone in the band download it to their own tablet+software combo of choice.

This works great for making sure parts don't get lost or forgotten, can practice tricky bits at home etc. etc. I'm a real fan. What doesn't work well though is getting "pencil" markings uploaded back to the drive. In practice, everyone marks up their own parts in their own software, but those markings never make it back to the originals on Google Drive. So if people swap parts, or a dep comes in, they're missing all that crucial info.

What do others do about this? Is there a good way to sync back markings on parts to the authoritative source of the parts?

[PhilTrombone]

One option: Keep a protected "originals" library with the clean source files in a separate place, from which you can restore the public copies. (extra work, requires twice the storage)

Second option: Don't allow individuals to overlay the Drive copies at all. Make it a one-way path. Once someone D/L's it to their tablet they can mark up as needed. If they want to back up their versions, they can do it someplace else. (this is the option used in a group I participate in. only admins can update the common area)

[Matt K]

What I do for my band is version each of the parts with a date and then make any pencil changes across the whole score. It's a little tedious, but I wrote all our tunes in Dorico with a template, so once the part is done, it's not that bad to make changes. Every time I load the file, it puts "today's" date as the version, so that when I go to export it, it says at the bottom the modified date. If I make "non-breaking changes" (meaning, for example, if I only make changes to wind parts and not the overall form, the drummer might not have to load anything), I make a note of it in a change log.

The scores I've primarily written are for 4 parts (+ optional bass) plus rhythm section, so I wrote out four parts and have a score for each transposition, so effectively, each part can be played by trombone/tenor sax, trumpet, or alto sax, and the bari part by euph/tuba, bass trombone, or bari sax.

I have a Python script that runs on my NAS in the background, and when it detects changes to the exported files, re-uploads the files to a shared Google Drive after properly splitting and labelling the parts. People in the band have access to their "instrument" transposition, and I keep track of who played which part and fan that out for every gig.

This all sounds complicated, but in reality it's been incredibly effective and I rarely have to make changes after the first rehearsal, so usually for each song the guys in the band have to re-download something at most one extra time. My parts are pretty detailed and meticulous though, with little room for ambiguity. Any pencil markings remaining are going to almost certainly be unique to the individual. If you were using typical published charts, you wouldn't be able to take this approach.

If I were running a band with published charts, I'd keep a master index of all the changes that people should make to their own parts and try to play the ink as closely as possible. I would probably not be very successful as a bandleader if it weren't my charts though. I like having things spelled out MUCH more detailed than virtually everything I've ever read from a typical publisher.

[mgladdish]

One option: Keep a protected "originals" library with the clean source files in a separate place, from which you can restore the public copies. (extra work, requires twice the storage)

Second option: Don't allow individuals to overlay the Drive copies at all. Make it a one-way path. Once someone D/L's it to their tablet they can mark up as needed. If they want to back up their versions, they can do it someplace else. (this is the option used in a group I participate in. only admins can update the common area)

A protected "originals" lib sounds eminently sensible. There's always one "special" case who has to make their part illegible with nonsensical markings scrawled all over it. It's Google Drive, we're never going to hit the storage limit.

[mgladdish]

What I do for my band is version each of the parts with a date and then make any pencil changes across the whole score. It's a little tedious, but I wrote all our tunes in Dorico with a template, so once the part is done, it's not that bad to make changes. Every time I load the file, it puts "today's" date as the version, so that when I go to export it, it says at the bottom the modified date. If I make "non-breaking changes" (meaning, for example, if I only make changes to wind parts and not the overall form, the drummer might not have to load anything), I make a note of it in a change log.

The scores I've primarily written are for 4 parts (+ optional bass) plus rhythm section, so I wrote out four parts and have a score for each transposition, so effectively, each part can be played by trombone/tenor sax, trumpet, or alto sax, and the bari part by euph/tuba, bass trombone, or bari sax.

I have a Python script that runs on my NAS in the background, and when it detects changes to the exported files, re-uploads the files to a shared Google Drive after properly splitting and labelling the parts. People in the band have access to their "instrument" transposition, and I keep track of who played which part and fan that out for every gig.

This all sounds complicated, but in reality it's been incredibly effective and I rarely have to make changes after the first rehearsal, so usually for each song the guys in the band have to re-download something at most one extra time. My parts are pretty detailed and meticulous though, with little room for ambiguity. Any pencil markings remaining are going to almost certainly be unique to the individual. If you were using typical published charts, you wouldn't be able to take this approach.

If I were running a band with published charts, I'd keep a master index of all the changes that people should make to their own parts and try to play the ink as closely as possible. I would probably not be very successful as a bandleader if it weren't my charts though. I like having things spelled out MUCH more detailed than virtually everything I've ever read from a typical publisher.

v. interesting.

I tried to do something a little similar with my own charts in Musescore - having the git hash as the version number populated automatically as part of the publish step of exporting the PDFs. I found MuseScore's scripting support woefully inadequate though :/

In this case, we're all playing from PDFs. A master changelog per chart would be a major pain in the bum - some of these charts are quite old and there are wrong notes, missing articulations, dynamics etc across a bunch of the parts. And everyone trying to step through a changelog to mark up their own copies would inevitibly lead to tears. Both theirs and mine.

I think I've found MobileSheets can sync your device with a remote library, but the online docs are superficial at best. And presumably that's no help for those in the band using ForScore or something else entirely.

[Matt K]

I think I've found MobileSheets can sync your device with a remote library, but the online docs are superficial at best. And presumably that's no help for those in the band using ForScore or something else entirely.

I don't know what its like on that side of the pond, but I'm basically the only person I know who has used Mobile Sheets, and I used a Surface Tablet for it, not an Android. Virtually every musician I know who uses a tablet uses an iPad and combines it with cloud storage like Dropbox or Google Drive or simply Air drops everything to one another. Hopefully forScore makes it easier for bandleaders at somepoint but in lieu of that I try to work around it as much as I can. It takes forever to get it "right" but boy it saves a lot of time to have charts that don't need to have much - if anything - written on them.