11-05-2024, 07:05 PM
Hi, all,
I play in a professional handbell ensemble (Sonos, www.sonos.org) and we play on a bunch of instruments (200+). We have 12 musicians who read off of 8 books, so most books are read by 2 musicians. Our scores are laid out using a typical grand staff and look like piano scores with extra symbols for handbell-specific articulations and expressions. We use all paper at this time. For background, most handbell groups use standard height tables with a layer of 3- or 4-inch foam rubber on which the instruments lay. We currently play with 34-ft of tables with instruments from C2 to E8 (handbells are octave transposing instruments). Each musician has their own personal copy of the music for individual practice as well as the books that we read from on the table, which means we have 20+ books all together.
We typically use a blue/red marking scheme for score annotations, where the player to the left of the book makes their annotations in blue pencile and the player to the right of the book uses red for theirs. Our music has been growing increasingly complex - our latest tackle is the Borodin Polovtsian Dances #17, which is extremely demanding and has many instruments loaded on the tables and thus we have a pretty significant number of markings in our scores.
This is becoming unmanageable and we've increasingly found it difficult to come to agreement on who is actually supposed to play what. So here's what I want to do:
1. Have a single cloud location for a score and all of its associated metadata (mainly markings organized as annotations).
2. The score will have annotations containing markings for each of the books on the table. When a piece is first being worked on, a leader (typically me) will do the thankless work of breaking down a full score into individual "parts" and then assigning those parts to each musician. (There is not a "best practice" for this strategy, but we use a time-honored tradition of assigning a consecutive range of notes to each musician and divvy up the entire range that way.)
3. Each book will have its own annotation layer, so I would create layers called "Book 1", "Book 2", etc. In those layers I would describe in text the overall breakdown (Blue (left) has this range of notes, red (right) has this range, etc.). I would also make additional markings to indicate changes from that overall breakdown in specific places, such as circling some notes or crossing out others in blue or red, depending.
4. Synchronize the shared "master" score to everybody's devices, including the tablets used on the tables (see what I did there?) and people's private devices for their own practice.
5. During rehearsals, musicians inevitably make changes to the initial markings I made. They'll make those changes in their own "book." These markings then need to be "uploaded" to the master so everybody can see them. The changes then need to be automatically synchronized to the tablets.
6. In this way everyone is always working from the latest, greatest set of markings.
7. During rehearsals early in the season, LOTS of changes are being made to markings by musicians all at the same time, so we need to be able to edit different annotation layers at the same time - can't have a "lock file; make changes; unlock file; resynchronize" gatekeeping system.
Crud, I know that's a lot of text. If you've gotten this far, thanks! I've read the MoSh manual and it seems to only support one-way synchronization, namely from a cloud directory down to devices, but I need two-way synchronization such that musicians can make changes on their individual devices and then "push" those changes up to the cloud directory. This is sort of like version control, I guess, and I imagine that it would work the same way - if two people are simultaneously pushing changes that don't "conflict" with each other, then no resolution is required and the cloud data is easily updated. For us the scope of change would always be in the annotation layers and two people would never try to change the same annotation layer at the same time.
Sorry again for the wall o' text and I hope that I can learn from y'all how to tackle this problem!
---Jason
I play in a professional handbell ensemble (Sonos, www.sonos.org) and we play on a bunch of instruments (200+). We have 12 musicians who read off of 8 books, so most books are read by 2 musicians. Our scores are laid out using a typical grand staff and look like piano scores with extra symbols for handbell-specific articulations and expressions. We use all paper at this time. For background, most handbell groups use standard height tables with a layer of 3- or 4-inch foam rubber on which the instruments lay. We currently play with 34-ft of tables with instruments from C2 to E8 (handbells are octave transposing instruments). Each musician has their own personal copy of the music for individual practice as well as the books that we read from on the table, which means we have 20+ books all together.
We typically use a blue/red marking scheme for score annotations, where the player to the left of the book makes their annotations in blue pencile and the player to the right of the book uses red for theirs. Our music has been growing increasingly complex - our latest tackle is the Borodin Polovtsian Dances #17, which is extremely demanding and has many instruments loaded on the tables and thus we have a pretty significant number of markings in our scores.
This is becoming unmanageable and we've increasingly found it difficult to come to agreement on who is actually supposed to play what. So here's what I want to do:
1. Have a single cloud location for a score and all of its associated metadata (mainly markings organized as annotations).
2. The score will have annotations containing markings for each of the books on the table. When a piece is first being worked on, a leader (typically me) will do the thankless work of breaking down a full score into individual "parts" and then assigning those parts to each musician. (There is not a "best practice" for this strategy, but we use a time-honored tradition of assigning a consecutive range of notes to each musician and divvy up the entire range that way.)
3. Each book will have its own annotation layer, so I would create layers called "Book 1", "Book 2", etc. In those layers I would describe in text the overall breakdown (Blue (left) has this range of notes, red (right) has this range, etc.). I would also make additional markings to indicate changes from that overall breakdown in specific places, such as circling some notes or crossing out others in blue or red, depending.
4. Synchronize the shared "master" score to everybody's devices, including the tablets used on the tables (see what I did there?) and people's private devices for their own practice.
5. During rehearsals, musicians inevitably make changes to the initial markings I made. They'll make those changes in their own "book." These markings then need to be "uploaded" to the master so everybody can see them. The changes then need to be automatically synchronized to the tablets.
6. In this way everyone is always working from the latest, greatest set of markings.
7. During rehearsals early in the season, LOTS of changes are being made to markings by musicians all at the same time, so we need to be able to edit different annotation layers at the same time - can't have a "lock file; make changes; unlock file; resynchronize" gatekeeping system.
Crud, I know that's a lot of text. If you've gotten this far, thanks! I've read the MoSh manual and it seems to only support one-way synchronization, namely from a cloud directory down to devices, but I need two-way synchronization such that musicians can make changes on their individual devices and then "push" those changes up to the cloud directory. This is sort of like version control, I guess, and I imagine that it would work the same way - if two people are simultaneously pushing changes that don't "conflict" with each other, then no resolution is required and the cloud data is easily updated. For us the scope of change would always be in the annotation layers and two people would never try to change the same annotation layer at the same time.
Sorry again for the wall o' text and I hope that I can learn from y'all how to tackle this problem!
---Jason
