home tune search software learn abc discuss about blog Starbound/LOTRO contact  

  [abc standard: home | current | route-map | updating | proposals]

 

Playback timbres

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.

GM timbre numbers [TN]

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.

MIDI percussion [MP]

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].

User-defined percussion [UDP]

[TODO, in conjunction with display]

Usage within overlay or tied notes [OTN]

If "I:timbre …" appears in the midst of an overlayed passage, the change of timbre (e.g. pizzicato / arco) must take place at its time position for all branches.

Example:

I:timbre GM Violin
c4 "^pizz."[I:timbre GM Pizzicato Strings] d2d2 & E4 G2G2| % the E4 must still have the bowed violin timbre

The second line is completely equivalent to

c4 d2d2 & E4 "^pizz."[I:timbre GM Pizzicato Strings] G2G2|

If a change of timbre occurs in the midst of a sounding note, either tied or by overlay, this note is not considered to change its sound. Playback software and "hardware" is not required to reflect this case perfectly; the note may well be shortened.

Timbre of chord symbols [TCS]

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 and subject to the "loose interpretation" regulation.

Hints for implementation [HFI]

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.

Proposer's comments

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/ ).

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

Is this essence or formatting? [EF]

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.

Why the additional keyword "GM"? [YKGM]

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.

Why is the default timbre "Piano"? [YDTP]

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

Overlay considerations [OC]

(About the [OTN] chapter). The example given is absolutely realistic, since the pizzicato timbre with "double stops" can occur anywhere in string music.

New scope notion:

Typical voice-related items, e.g. "octave=", will apply strictly to the code following it in the respective voice, including overlay passages which go back in time. Some (very few) other voice-related types, including "I:timbre" and ottavas, refer to the notes in that voice to be played at that time position and afterwards and must therefore behave differently, as described above. We may want to introduce a scope "voice-time-related" for these types and describe their behaviour centrally.

If we do so, the text would start "The voice-time-related 'I:timbre' keyword…"

Why must %%MIDI become obsolete, rather than just deprecated? [YMO]

  • The variants that include a voice ID are not idiomatic abc.
  • Much worse, their scope is undefined when found in mid-tune.
  • The scope of other directives, e.g. "\%\%MIDI chordprog", is undefined as well.
  • The variants that include a MIDI channel number are ill-defined; the 2.1 document has them only in the "Canzonetta" example.
  • 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 propriatory usage, and MIDI is such a propriatory command for abc2midi. If we decide to share this (somewhat dangerous) view, "MIDI ..." will be a mere comment from the standard's point of view, whereas "I:MIDI ..." provokes an error message. === Why "I:timbre MIDI-percussion"? [YMP] === 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.

Should we not also standardize directives for ...?

… 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.

This is the criterion for any extension that may be proposed in the future. For the above questions, my answer is: rather not.

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.

abc/standard/v2.1/proposals/timbres_midi/alexmidicond/v1.txt · Last modified: 2013/03/02 12:24 by alexmidicond
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki