The failure of Finale’s Percussion Mapping in 2010+

Fairly recently the Tulane University Marching Band upgraded their version of Finale from 2009 to 2011 in an attempt to stay current with the new software. It was only about a week ago that i discovered that since Finale 2010 they did a complete overhaul of the Percussion Mapping feature. Initially when i looked at it, i thought “wow, that’s different, but it looks like it’s an improvement.”

Tonight i discovered that the change is an absolute disaster.

In order for it to be clear why the new system completely fails, you need to have an understanding of how the pre-2010 system works. Pre-2010 perrcussion mapping is set up via the following screen:

There are four important elements for a pre-2010 map:

• MIDI Key: the first number, which is the note you press on your MIDI keyboard.
• Playback Note the second number, which is the *actual* MIDI note heard when you press the MIDI Key.
• Notehead Position, as in where the note appears on the staff.
• Notehead Style, as in what actual notehead is used for the MIDI Key.

The MIDI Key is, well, key to the success of the use of the map. Here’s how the screenshot breaks down:

MIDI Key 48 shows my “snare drum” map route. When i hit note 48 on my MIDI keyboard, it actually plays back MIDI note 50, puts it on the top space of the staff with a closed notehead.

MIDI Key 49 is my “snare drum cross-shot” map route. When i hit note 49 on my MIDI keyboard, it plays back MIDI note 58, puts it on the top space of the staff with an X notehead.

MIDI Key 50 is my “snare shot” map route. When i hit note 50 on my MIDI keyboard, it plays back MIDI note 51, puts it on the top space of the staff with an empty circle notehead.

Basically, i can remap the entire MIDI keyboard to playback whatever MIDI note i want and have it appear where i need to on the staff with whatever notehead i want. Why is this so important? Because it allows me to easily plot my MIDI keyboard into different areas that i use for marching percussion sounds and group “sections” together on my keyboard even if the sounds themselves are scattered across the actual MIDI keyboard.

My basic battery setup, for example, uses the octave between C2-C3 for all things relating to snare, C3-C4 for all things relating to tenors, C4-C5 for all things relating to bass drums, and C5-C6 for all things relating to cymbals. For bass drums, C4 is bottom bass, D4 is bass 4, E4 is bass 3, F4 is bass 2, and G4 is bass 1. Low to high, all in a row. Stick clicks for those bass drums are set up on the accidentals in that octave. C#4 is bottom bass stick click and shows up as an X on the bottom space. A#4 is the top bass drum stick click and shows up on the top space. And since there’s only one stick click sound, all of those stick clicks are mapped to the same MIDI note.

A more complex example is when i had to write for a multitude of percussion instruments that were being passed between player to player depending on the part of the show, and i had to make sure that both the notation was correct for the players and that the playback was correct for our color guard and dance team to have something to choreograph without the need for a live recording. for this, i came up with this percussion map scheme:

In a nutshell, i had to use a single percussion map to deal with al of the percussion and the easiest way to map it was to group the various elements together on the MIDI Keyboard and then map it to the appropriate playback note. This made using Speedy Entry very intuitive once i got used to the map, and if i wanted to, i could have changed it around without too much difficulty if anything turned out to be a logistical issue.

The ability to create a custom Keyboard map is something that i’ve relied upon ever since percussion maps were introduced years ago – and when MakeMusic decided to overhaul the percussion mapping, they took customization of keyboard maps out.

This is what the percussion map screen looks like now:

Ignore the lack of MIDI Key for a moment and it looks pretty much the same but with some improvements. You can specify custom noteheads for more than just open or closed, and the “note type” replaces the need to know specifically what your “playback note” is, as Finale now makes it more descriptive as it relates to what the actual sound is. I like this pretty well as people who want to make use of percussion sounds but aren’t familiar with the typical GM MIDI percussion map have to go searching for the right MIDI pitch and find the sound, and for sound libraries like the Garitan instruments and Tapspace, there are a wealth of sounds that don’t map to the typical GM percussion paradigm so assigning “numbers” to those makes no sense.

But with the percussion mapping revamp came a devastating conceptual change that for the likes of me makes it utterly useless: the decision that Note Type would replace MIDI Key as the “primary key” that thus defines the mapping.

In the world of data programming, the “primary key” is what is used to differentiate all attributes of a particular record in a table of records. The primary key is usually a number or a an alphanumeric combination that must be unique so that the technology can always identify it uniquely even if other elements of the records are exactly the same. The primary key is usually hidden to the end user as that number is meaningless to their use of the data.

As an example, take an Oracle ERP system that has a table with the fields [first name] [last name] [address 1] [address 2] [city] [state] [zipcode]. All of those fields are searchable. The end user needs to find anyone in the system whose last name is “Wilson”. So they bring up a search box, type in “Wilson”, and a list of names appear. They select one of those names, say “Bob Wilson”, and a screen pops up with all of Bob Wilson’s info.

To the end user, their identifying criteria is “Bob Wilson”. There might be more than one Bob Wilson in the system, but regardless, the end user is starting with a basis of “Bob Wilson” and then determining whether or not that’s the record that they want by then looking at the rest of the data to see if it matches what they need.

To the system, when the end user clicks on that “Bob Wilson” to bring up the screen with Bob’s info, the system doesn’t know that “Bob Wilson” is being clicked. The only thing that the system knows is that “end user selected this record which has associated with it this primary key, so i will now fetch information related to this primary key”, which is probably a number like “45251”. If the primary key didn’t exist, the system would have to do a bunch of what-ifs to ensure that the record that the end user clicked actually corresponds to the data held in the record. That means that even if the search table displayed just names, it would have to load all of the record information in the back end to associate it with each individual record, and then do checks once the record is actually selected. That’s inefficient programming and data management and can cause a plethora of issues. With unique primary keys, records can be fetched according to one criteria and one criteria alone.

With the pre-2010 percussion mapping, what i’m calling the MIDI Key was the primary key. You press that primary key on your keyboard, it shows up on this part of the satff with this notehead and plays back this note.

With the post-2010 percussion mapping, it’s clear that they reprogrammed it so that the Note Sound is now the primary key. Conceptually this seems like an arbitrary change, but it’s had two huge adverse effects: First, it’s made it so that there’s no way to assign a MIDI note on my keyboard to map specifically to that sound for the purpose of Speedy Entry. There is a feature called the “MIDI Map Editor” that appears to do this:

(and never mind that this is now in a separate window that is not only non-intuitive in how you enter each note for the map, but shows up pretty much only in the order that you enter them and is not otherwise sortable)

But while it does indeed change the map so that pressing MIDI note 53 will map to how i have “Bass Drum 2 (2)” notationally, it also changes the sound to MIDI note 53 under the assumption that i really want the “bass drum” to sound like whatever MIDI note 53 happens to be – which in this case i believe is a crash cymbal.

Therefore, there’s no way to map MIDI note 53 on my keyboard to both show up on the right part of my stave *and* playback the note that i want. Instead, i’m forced to either not care about what the playback sounds like which i can’t do because we use those MIDI recordings to help the color guard and dance team do what they need to do, or i’m forced to use the actual MIDI note that’s assigned to that sound which is inconvenient because they can be spread out across the MIDI keyboard as opposed to being right at my fingertips.

Secondly, because each Note Sound is now the primary key and therefore must be unique to each map, i can no longer have the same sound assigned to different parts of the staff. In my pre-2010 map, there was one rim click sound i used for all of my bass drums regardless of where the X notehead was on the staff. Here, if i were to assign the “bass drum rim” note sound to a spot on the staff, i cannot use that same sound anywhere else in the same map. So a single “bass drum rim click” sound is restricted to only showing up once on the staff.

Finale kind of takes care of this by assigning every bass drum with its own rim click sound, but there’s only one set of sounds for solo cymbals. So if i’m writing for a five person cymbal line, i cannot have the same “crash” sound or the same “hi hat” sound appear on different spaces on the stave – and i have no alternative sounds that i can use to rectify this. The only potential alternative – one i haven’t explored – is to pull up yet Another Menu regarding custom sounds, assign the duplicate sounds to different slots in the custom sound bank, and then find a way to remap that to show where i want to on the staff and with the MIDI keyboard note that i want.

In other words, a big pain in the ass involving at least four configuration screens that can’t be open at the same time that prior to Finale 2010 was a single configuration screen.

After a quick google search about this issue, i came across a few threads on the makemusic forums that have shown that other users who have complained about this issue to email and telephone support have been generally ignored, with statements like “you must be doing something wrong” or “this problem must be very unique to you as people worldwide love the new percussion mapping.” Through the entire release of Finale 2011b over a year later this has not been resolved despite numerous complaints and assurances that “we’re taking your feedback seriously”.

What’s silly is that it’s very possible and even likely that the feedback is being taken seriously, but the reality of the situation seems to be similar to issues i encountered when i was working at Symantec and huge new code rolled out into production – if the code that rolled out made significant improvements but had a bug or created more confusion in other minor aspects of the interface, the new business process would not allow it to roll back, and the change in architecture was so heavy that trying to bring back old functionality/practicality would require coding that might as well have been a start from scratch for something that globally the company sees as such a small detail that it’s pushed to the bottom of the priority list.

The conclusion? Given how vital percussion mapping functionality is to my job and career, I’m not going to use anything past Finale 2009 until i’m assured that this key issue is fixed in a way that is intuitive and works with the same sort of versatility and functionality that i use it now. Since i don’t have faith that the issue is going to be resolved to my satisfaction any time in the near future based on some initial back-and-forth on the forums about Finale 2012, it may be the right time to jump ship and switch to Sibelius.