1. Carry - within a group of consecutive i statements whose p1 whole numbers correspond, any pfield left empty will take its value from the same pfield of the preceding statement. An empty pfield can be denoted by a single point (.) delimited by spaces. No point is required after the last nonempty pfield. The output of Carry preprocessing will show the carried values explicitly. The Carry Feature is not affected by intervening comments or blank lines; it is turned off only by a non-i statement or by an i statement with unlike p1 whole number.
An additional feature is available for p2 alone. The symbol + in p2 will be given the value of p2 + p3 from the preceding i statement. This enables note action times to be automatically determined from the sum of preceding durations. The + symbol can itself be carried. It is legal only in p2. E.g.: the statements
i1 0 .5 100 i . + iwill result in:
i1 0 .5 100 i1 .5 .5 100 i1 1 .5 100Another useful feature for p2 is the use of the "^" symbol. This allows an event to be positioned relative to the previous event for the instrument. It behaves like + except it is based on the start time of the previous event. It permits motifs to be moved easily. So:
i1 0 10 i1 ^+5 . i1 ^+8 .will result in:
i1 0 10 i1 5 10 i1 13 10The Carry feature should be used liberally. Its use, especially in large scores, can greatly reduce input typing and will simplify later changes.
3. Sort - this routine sorts all action-time statements into chronological order by p2 value. It also sorts coincident events into precedence order. Whenever an f statement and an i statement have the same p2 value, the f statement will precede. Whenever two or more i statements have the same p2 value, they will be sorted into ascending p1 value order. If they also have the same p1 value, they will be sorted into ascending p3 value order. Score sorting is done section by section ( see s statement). Automatic sorting implies that score statements may appear in any order within a section.
N.B. The operations Carry, Tempo and Sort are combined in a 3-phase
single pass over a score file, to produce a new file in orchestra-readable
format ( see the Tempo example). Processing
can be invoked either explicitly by the scsort
command, or implicitly by csound which processes the score before calling
the orchestra. Source-format files and orchestra-readable files are both
in ascii character form, and may be either perused or further modified
by standard text editors. Userwritten routines can be used to modify score
files before or after the above processes, provided the final orchestra-readable
statement format is not violated. Sections of different formats can be
sequentially batched; and sections of like format can be merged for automatic
sorting.