The & operator may be used to produce several musical sequences (= effective voices) within one measure of one abc voice. Typical usage is for very short passages where a voice splits up in a way that cannot be covered by mere "[]" chords.

Each & operator sets the time position of its voice back to the previous bar line (or, if none exists, to the beginning of the voice), and the notes which follow it form a temporary voice in parallel with the preceding one. More such overlay sections can follow, each separated by an & operator. An overlay ends at the next bar line, whose time position is set to match the longest section. Shorter sections are treated as if filled up with invisible ('x') rests.

[Examples]

Users who need special settings for particular overlay sections should consider using separate V: voices sharing a staff, for best flexibility and readability. Still, all abc types allowed in the body are available inside overlays as well.

1. w: and s: fields [WS]

The notes matching the syllables or symbols of w: or s: fields, respectively, are counted strictly in the order in which they appear in the code, disregarding all & operators (and thus possibly jumping back in time as well).

[Example]
[TODO: cross-linking with "5.1 Alignment" etc.]

2. Staff-related and control types [ST]

In overlay measures, items of staff-related or control scope are only relevant if found in the first section, i.e. before the first &. For subsequent sections, the regulations apply as if they were separate voices. The effect of those items always applies to their time position. Thus, if they are found in mid-measure, the following section initially jumps back to the previous setting!

(For the +/-8/15 clefs see clause 5. below.)

3. "Voice-time-related scope" [VTR]

Some types that are formally voice-related but have their effects in the displayed score for a time span, are treated like staff-related types with respect to overlay. These types include the following:

1. all decorations explicitly of "start…end" type, such as slurs "(…)" and "!<(! … !<)!", unless both delimiters are found in the same section of the same overlay,
2. the ^/_ variants of "I:ottava…". (As for the +/-8/15 variants, including the spelling !8va(! etc., see clause 5. below).

The reason for this regulation is that these time spans often start or end in different measures. Users who desire a truly voice-related behaviour with respect to individual sections, must transform these into separate voices sharing that staff.

(Note that the tie, see 4.11, poses no such problems, neither here nor in [] chords: it simply aims at the end of the note time, assuming there to be some note of equal or enharmonically equivalent pitch, no matter from which section it comes.)

4. Other voice-related types [OVR]

Values of all other voice-related types apply to the code following the item, strictly disregarding all & operators. Users who want a value to be reset for the measures following the overlay, must insert another item to that effect. A typical example is

[K:stem=up] cdef & [K:stem=down] CDEF | [K:stem=auto] …

[TODO: we need "stem=auto".]

Note that this includes many types with graphical impact, even with a time-span meaning, for example !p!. Software may or may not attempt to interpret these as regarding their overlay section only. Again, users with more specific wishes must use separate voices.

Hint to programmers: When software internally maps an overlay section to a ghost voice - new or reused -, it must set all relevant values of that voice simply to those values that are active at the end of the previous section. The same applies when resuming the main voice after an overlay.

5. Sound-affecting clefs and ottavas [SACO]

For the purpose of this paragraph, all +/-8/15 types of clef and ottava are considered split into their two components:

1. The component equivalent to the ^/_ counterpart is treated according to its scope, staff-related or "voice-time-related", respectively.
2. The octave shift of the code is considered ordinarily voice-related, analogous to "octave=".

Users who insist on such clefs or ottavas in mid-overlay are strongly encouraged to position them so that no discrepancy between the two components occurs.

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.

This proposal assumes the spelling "clef=treble^8" etc. from the current draft 2.1.1, corresponding to "clef=treble+8n" etc. of my "Clefs" text.

To my knowledge, it was never implemented, for good reasons. The standard document seems to suggest that every section can go back an individual number of measures, which is pure chaos. See [XMB] below for a feasible syntax, similar to the one proprietary to abcm2ps.

Yes, we could decree that overlays only contain notes; anything else would remain "at the user's own risk" alias non-standard alias outlawed; this would be perfectly OK given the fact that explicit V: voices provide the full functionality.

The current standard effectively does that, but does give a regulation of the (implicitly interfering) w: and s: fields. Now people are likely to shout that decorations can do no harm (except for those that can, of course), and that this and that field "obviously" requires this and that regulation … In the end our list of exceptions would be much longer (and much more difficult to remember) than the above simple rules.

Some users may indeed imagine continuous "ghost voices" (one voice for all second sections, one for all third sections, etc.) as they are used internally by software, for example regarding the stem direction. Such users may be best served with genuine V: voices made more comfortable to use, see below.

Having ghost voices remember timbres etc. would only be of any use if they are always referenced in the same order. Consider for example a violin voice, the first overlay section being reserved for ordinary bowing, the second one for pizzicato, and the third one for harmonics. Since all three techniques rarely occur simultaneously, most overlay measures would have some empty sections, and the author and the reader must remember the exact setup. Who would want that?

It has been proposed that overlay sections get an ID for that purpose, which would make them pretty much resemble ordinary voices; see below.

The limitation of overlay to a single measure is sometimes considered too restrictive. Desired section lengths may not only comprise more than one measure (as suggested in the standard; see [YN&&] above), but - more crucially - less. The temptation to use "invisible bar lines" for the latter need (as recommended in "4.8 Repeat/bar symbols") is very dangerous, since it may corrupt

1. propagation of accidentals,
2. measure counting for Z/X rests,
3. and measure numbers for display.

In fact the syntax could be extended easily to cover sections whose length is independent of measures, with exactly the same scope regulations as above. We would only need a new type of item that replaces the bar line in its role of defining the start and end of an overlay, e.g. [I:ov], or even !ov(! … !ov)(! … !ov)!.

abcm2ps uses (& … &) in precisely these roles. This syntax looks a bit dangerous to me, but I do not see any manifest ambiguity. Any of these are OK with me.

Some users want parallel voices each of which remembers its own settings, e.g. of timbre or stem direction. For these purposes, and also for the [XMB] demand, our present V: mechanism offers all that is needed, in full flexibility. The two main drawbacks for the present use case are

1. that the voice replacing an overlay section contains many empty bars, which are tedious to count, and
2. that the reader of the code for the main voice cannot see easily where such a quasi-overlay applies.

The second drawback can be mended by inlining, but with no intrinsic guarantee of synchronousness:

I:score (vl vlpizz)
V:vlpizz stem=up
I:timbre GM pizz
V:vl
I:timbre GM violin
…. [V:vlpizz] X573 | .A x7 | [V:vl] …

To amend the first drawback, my old idea of a "synchronousness anchor" may be handy, something like

I:score (vl vlpizz)
V:vlpizz stem=up
I:timbre GM pizz
V:vl
I:timbre GM violin
…. [I:anchor pizz1] | C8 | [V:vlpizz] [I:anchor_to vl pizz1] | .A x7 | [V:vl] …

which could also be typed, shorter but slightly less readable, as

I:score (vl vlpizz)
V:vl
I:timbre GM violin
…. [I:anchor pizz1] | C8 | …
V:vlpizz stem=up
I:timbre GM pizz
[I:anchor_to vl pizz1] | .A x7 | …

(The [I:anchor_to …] field is equivalent to the required number of 'X'/'x' rests. Backward jumps are not permitted.)

This was dismissed earlier as "too complicated", but it is a whole lot simpler than overlay. This is the way to go if the desire arises, all the more since synchronization has many other use cases.

The following variant is a little shorter to type:

I:score (vl vlpizz)
V:vlpizz stem=up
I:timbre GM pizz
V:vl
I:timbre GM violin
…. [V:vlpizz pickup=vl][V:vl] | C8 | [V:vlpizz] | .A x7 | [V:vl] …

(When we last discussed this, someone suggested something like "[I:pickup vlpizz]" inside the "vl" voice - shorter indeed, but extremely dangerous, since it influences "vlpizz" from outside its V: range. No, no! Bad enough that T: forces synchronousness.)