cascading percussion notation problems and solutions

the initial problem: the drumline at tulane this coming year is pretty small (8 people), so the show is being written where each member plays multiple roles. To start, everyone is in percussion pods that are out on the field. At some point, they switch to traditional battery instruments of 3 snares, four bass drums, one cymbal. After that, half of those shed their drums to put on ethnic drums/timbales, then they move back to their pods, then they end on battery instruments again.

the challenge is how to write the parts in the full band score that make it easy to distribute the parts. Typically a marching percussion score consists of pit vs. battery where pit is one person per staff but battery is one section per staff. Since the percussionists are only playing as a battery for two sections of the show, having a single staff dedicated to bass drums makes no sense since it will contain a lot of empty measures and make it so that players have to shuffle between different parts to figure out what they’re playing when &c.

solution: each player gets their own individual staff, more like a pit score. The times in which they’re playing traditional battery, duplicate all of the parts on each staff.

resultant problem: to help with overall design for the color guard designer, the dance team choreogrpher, and the cheersquad, plus to aid with memorization and visualization of parts and tempos for the members, all of the parts need to actually sound like what’s going to happen on the field. Because of the roles being played, some players need to have assigned to them two different percussion channels for the sounds to be accurate (one for marching percussion and one for general percussion). This falls outside of my normal percussion notation paradigm of only needing two layers to deal with stems up vs. stems down; playback and notation together would require at least three if not all four layers that are available in Finale, and i’m limited in how i can configure layers 1 and 2 because they’re already being used by the wind instruments (and i can’t therefore manipulate global stem direction, treatment of ties, &c without mucking up how they appear elsewhere in the score).

Additionally, in the battery sections there are three staves that have the same snare part and four staves that have the same bass drum part. This is unnecessary duplication of MIDI output which will a) affect balance of the final MIDI output and b) cause dropped notes when the full ensemble is playing because of MIDI’s limitations, but i can’t just mute a particular person’s track or even a particular layer of a track because that layer may have unique parts in other parts in the show.

solution:

First, i created a single percussion map that encompassed all of the instrument sounds and notation for those sounds that i needed to use in the score:

I applied that map to every individual percussion staff in the score. Placement on the staff and notehead type of each individual sound is defined by the map, so use of a MIDI controller is necessary to ensure that the correct map path is used. (In other words, mouse-clicking a note on E4 could mean either bass drum 2, snare, snare rim shot, snare crossshot, drum set tom 1, cymbal player crash, cymbal player hi hat, or cymbal player slide choke, and determining which is a pain. Playing the correct “map” note on the keyboard will place the note on E4 but also ensure that it’s mapped to the correct sound.)

Once all of the parts are placed in the score, I muted all of the percussion staves. I created a new stave, called “playback”, and had the first layer assigned to the marching percussion channel and the second layer assigned to the general MIDI percussion channel. I copied a single version of all of the necessary parts into that playback staff and then made that playback staff invisible in the final score.

The playback staff doesn’t look pretty, but it’s not supposed to. FOr some of the more layered sections i might try to separate some of it into a spare layer just for the purposes of easier debugging, particularly if there are ever any changes that are made to the score that i will then need to change in playback.

originally posted on darkblog resonate.

Leave a Reply!