The voice-related type "I:timbre" is used to give rough hints to the playback software about the sounding timbre of the voice. It does not make any assumption about technology, so that it is safe (and recommended) to use in communicated code. Nevertheless, for simplicity and universal compatibility, it borrows its values from the General MIDI norm (http://en.wikipedia.org/wiki/General_midi).

It is not meant to be noticed by any other type of software, such as display or database programmes. It has no impact on transposition.

The following syntax stands for General MIDI timbre numbers:

I:timbre GM0 <number> % zero-based "General MIDI program number", 0 - 127
I:timbre GM1 <number> % one-based "General MIDI program number", 1 - 128
I:timbre GM <timbre name>

where <timbre name> is one of 128 names, mapped to a one-based "program" number as follows:

[Insert one-based list from http://www.midi.org/techspecs/gm1sound.php , or zero-based from Wikipedia. Perhaps we should have a column of abbreviations for some of the most popular names, such as "Piano" and "Horn".]

Upper/lower case, space characters, parentheses, and hyphens are optional.

For example, the following lines are equivalent:

I:timbre GM0 29
I:timbre GM1 30
I:timbre GM Electric Guitar (muted)
I:timbre GM electricGuitarMuted % but never drop the part inside the parentheses!

The pro-forma default value is "GM0 0" (Acoustic Grand Piano), but authors of playback software are encouraged to let their users choose a different default value.

I:timbre MIDI-percussion

states that the notes of the voice should sound as mapped to various percussion instruments by the MIDI percussion norm. (If the software actually uses MIDI, the effect is obtained simply by sending the notes on MIDI channel 10.)

To obtain a satisfactory display of such voices, further information is required, see [TODO].

The regulations of percussion maps ([TODO, in conjunction with display]) imply percussion timbres, so that no "I:timbre …" must be used simultaneously. Any "I:timbre …" encountered later in the same voice would override the percussion map, which is hardly desired.

Playback of chord symbols is not (yet) standardized and has many more aspects than just timbre. Still, users who want to provide a hint about it may specify

I:chord-timbre …

with exactly the same regulations as "I:timbre …".

All "%\%MIDI …" directives are obsolete, mainly because of unresolved scope problems and ambiguities. Software should tacitly ignore them if found in a tune that also contains "I:timbre …", since they are then assumed backups to work with older playback software. Otherwise they are cases for "loose interpretation".

Playback or conversion software may be limited in the number of simultaneously active timbres, for example by the number of available "MIDI channels". The programmers should be prepared for the case that an abc tune exceeds these limitations. If they cannot fulfill the user's wishes exactly, they should replace some timbres by similar ones. As a minimal requirement, sustained sounds should never be replaced by fading ones, nor vice versa.

My name is Alexander Scheutzow, I am a professional software architect and developer, also the author of the abc tool MidiZyx2abc and of the more widely known MIDI software MidiCond ( http://www.midicond.de/index_en.html ).

Suggestions for improvements are welcome in the forum http://tech.groups.yahoo.com/group/abcusers/ - my user name there is scheutzow4cond. Thank you.

According to Wikipedia (arguable, as usually), timbre is "the quality of a musical note or sound or tone that distinguishes different types of sound production, such as voices and musical instruments, string instruments, wind instruments, and percussion instruments." The word is sometimes used to distinguish between different instruments of the same species, but can well be used to compare different instruments: "The timbre resembles a clarinet".

The keyword "instrument" would convey an inaccurate idea, not only because "Choir Aah" is a GM timbre as well. More importantly, I:timbre is not meant to make a statement about the intended performer of the sheet music, but merely suggests an approximation for playback software; the instrument will always be an electronic sound module. In practice, "GM clarinet" must double for the bass clarinet, etc. Besides, "I:instrument" is too easy to confuse with the proposed voice parameter "instrument=" and other notational properties of instruments.

"I:program" would only make sense in the MIDI context, where it stands for the ancient act of programming a synthesizer module.

It is not essence in the strictest sense, in fact much less essential than clefs. Nevertheless, publishers of abc code are recommended to include timbres, thus they is not "mere formatting". We may introduce a hierarchy of "essentiality":

1. Holy Essence from the composer, which must never be touched by anybody else
2. Essential editor's work, including clefs & ottavas
3. Circumferential editing, including timbres and the specification of preferred / unpreferred page break positions
4. Formatting depending on the recipient's software etc.

For the name syntax, "I:timbre Violin" may seem sufficient at the moment, but there may be other kinds of timbre directives in the future. It is important that they all use the same main keyword "timbre", so that it is clear that each such directive overrides the previous one.

For legacy reasons: it is the default program of the MIDI norm, and some existing piano parts may rely on that.

The timbre is now an ordinary voice-related type in the sense of my new overlay concept. When found in mid-overlay, it strictly applies to the *code* following it. This enables parallel usage of several timbres in the same voice, notably left-hand pizzicato with simultaneous bowing of string instruments. Implementors

• The variants that include a voice ID are not idiomatic abc.
• Much worse, their scope is undefined when found in mid-tune, which means that their time position is undefined!
• The same applies to "MIDI program <channel> <program>", according to Seymour's definition * The same applies to some other directives, such as "\%\%MIDI chordprog". * "MIDI program <channel> <program>" is ill-defined; the 2.1 document has them only in the "Canzonetta" example. (Wim understood it differently.)
• "MIDI channel" is unnecessarily restrictive; abc should not worry about MIDI channels at all: some playback software might not have such restrictions. As with all obsolete stuff, software may **try** to make the best of it but should issue a warning or error message. According to Jef, fields are free for proprietary usage, and MIDI is such a proprietary command for abc2midi. If we decide to share this (somewhat dangerous) view [TODO], "MIDI …" will be a mere comment from the standard's point of view, whereas "I:MIDI …" provokes an error message.

The above regulation [OBS] should be on the safe side, for the time being.

Indeed, there is currently no way to *display* MIDI percussion voices, and this directive cannot change that. But at least it gets the sound right, replacing the old "%%MIDI channel 10". Import software such as MidiZyx2abc relies on such a function.

Our final percussion concept must provide an easy way to achieve the same effect plus reasonable display. "I:timbre MIDI-percussion" may or may not survive. The concept must also offer methods for hand-typing note names for drumset voices, oriented at the treble clef and bass clef.

Many ordinary notation programmes have "instrument objects", preset and user-defined, i.e. collections of settings for particular instruments, so that they can be referenced by (= collectively assigned to) particular voices, and reused. Such a concept is not suitable for abc, since it cannot hide those lengthy definitions from its readers.

Authors of tutorials are encouraged to offer typical "voice headers" including timbre and transposition, for users to copy-and-paste and delete any settings that they are not using in this voice.

… the stereo panorama position? Volume, absolute or in reaction to dynamic signs? Speed of trills? Execution variants of trills, rolls, …?

In my opinion, the abc standard should only worry about playback to the extent sufficient for ear control. Timbres are very valuable for this, and the above method of communicating them is safe and detailed enough to be of use for all recipients. (Besides, they are particularly easy to implement using MIDI, whereas panorama and volume are very problematic when running out of MIDI channels.)

A general criterion for standardizing any new feature is: Will it be expected in published abc code, to convey the author's knowledge about the piece of music, rather than mere taste?

For the above questions, my answer is: rather not. (However, I might welcome "I:chord-style …" for the playback of chord symbols, with possible values "carpet", "oompah", "arpeggio", etc., but that is a different topic.)

Anything else is "style sheet". Programmers of playback software are encouraged to offer all kinds of gimmicks, driven by clever algorithms or by additional commands, either proprietary or of "style sheet" type. For example, violin voices may by default be positioned at the left stereo position, basses at the right.