global.sound vs Finale

[rpatters1]

The new global.sound object appears to map to a single element of Finale's percussion map concept. The thing is, Finale files typically contain dozens of percussion maps, each mapping a specific synth patch's instrument layout.

What is the envisioned way to import these to global.sounds? Even if I limit the export to percussion maps used in the file, it seems that MNX itself will lose valuable information around which patch each sound belongs to. (I can preserve it some sort of proprietary naming scheme for the keys, but this would be opaque to consuming software.)

[adrianholovaty]

Apologies, I need to add a proper example document that demonstrates how that works. The overall intended approach is:

• The document's global.sound defines all the percussion sounds used in the document, each with a string ID.
• A part defines a "kit" object, which is a dictionary mapping user-supplied keys to "kit component" objects.
• Each "kit component" defines its soundID.
• Percussion events use "kit notes" instead of "notes" to encode their notes.
• Each kit note has a required "kitComponent", which is the ID of the kit component. This ID corresponds to a key from the part's "kit" object.

Hopefully that makes sense?

We definitely plan to expand the "sound" object to include additional metadata about the sound — which would include any necessary information on how to locate the sound in a synth engine (patch numbers, etc.). If you have some suggestions on some standardized data we can put in there, I'd love to hear them!

[mscuthbert]

A discussion point was whether a Part has one or more than one percussion mappings generally defined. There was some disagreement on this topic which expertise in the field could help clear up.

Having many maps in the doc (even if some are never used) would be an interesting extension. I like to consider how an mnx document might be used as a "template" and for that use case this would be a pro. For the specific case of "1 file =1 score" it has less applicability.

[rpatters1]

I have done some analysis on how Finale handles similar issues. It looks to me like global.sounds maps best to Finale's "percussion note type" concept. These are effectively a hard-coded list, though actually they are encoded in a CSV file that is distributed (on macOS) inside the app bundle or (on Windows) alongside the executable. Useful values in percussion note types are the name, the General MIDI number (or -1 if not applicable), and a default staff position.

In addition, a set of xml files is distributed with Finale and stored in a support files location that is appropriate for the OS. There is one xml file per known virtual synthesizer. These are

• SmartMusic SoftSynth
• NotePerfomer
• Garritan Instruments
• General MIDI
• Tabspace Drumline

Each xml lists the percussion patches available on that synthesizer and includes a name, a display name (usually the same) and a mapping from a MIDI key number to a value from the hard-coded percussion note types list.

Finally, the default Finale document contains a long list of named "percussion maps" that choose a subset of percussion note types from a particular synth patch along with their MIDI <-> percussion note-type mappings. A percussion map can be assigned to a staff ("part" in MNX parlance). These percussion maps seem to map best to part.kit, with the proviso that parts draw from a predetermined list of kits (which the user can edit).

In addition to percussion note type and staff position, percussion map elements include codepoints for filled, unfilled, whole, and double-whole noteheads. The font for the noteheads is determined by a percussion notehead font value which is usually (but not necessarily) the same as the music font. Like any notehead in Finale, the default glyph and font of a percussion notehead can be overridden on a case-by-case basis.

Notes on a staff are tied to percussion maps by means of the percussion note type. If the note has an annotation specifying a percussion note type, and if the staff is set up for percussion notes, then the note uses the mapping value for that percussion note type. Its pitch information is ignored in favor of the staff position in the percussion map element.

It looks to me like the "percussion note type" is designed to allow Finale's designers to pre-map percussive sounds so that, e.g., a Bass Drum is a Bass Drum on any choice of synthesizer patch. That allows the user to change the playback synth and/or patch without having to then go back and remap all the notes.

[rpatters1]

Yes, I understand the kit concept (I'm fairly sure). After digging a little further, I realize that global.sounds may correspond better to Finale's "percussion note type" concept. This list is much more manageable.

The issue is, depending on the synth patch for the part, "Concert Bass Drum" might have MIDI note C2 in one patch and G2 in another. There may need to be a little more thought given to the midiNumber key.

[rpatters1]

I suppose for now I will put General Midi codes in midiNumber if they exist. That seem the thing that would be of most interest to a consumer of the file. But I think it needs clarification exactly what should go there.

[rpatters1]

In answer to your more general comments, if I have correctly mapped the concept of percussion note type to the sound object, another possibly useful fields might be the default staff position. The documentation does not mention percussion with respect to sound, which suggests the committee is imagining it may be used for any sounds. But then, midiNumber makes less sense if it is not a percussive sound.

[rpatters1]

Actually, I do have a question about how it is now. The kit component has both a name and an optional soundID that points to global.sounds where another name is to be found. What is a use case where these names would differ?

[rpatters1]

Another idea from Finale is the kit component might also include glyph names for filled, unfilled, whole, and double whole noteheads.