The score section contains events that instatiate instruments from the orchestra. There are various score statements that enable complex score building within the csound language.
Currently, the maximum length of the score is 2^31-1 control periods. For example, with kr=1500, you can run a score for a maximum of about 16.5 days before problems occur due to overflowing signed 32-bit integer variables.
Note also that when using single precision floats (i.e. the 'f' installers rather than the 'd' ones), the accuracy of timing becomes worse after performing for a long time.
A Score (a collection of score statements) is divided into time-ordered sections by the s statement. Before being read by the orchestra, a score is preprocessed one section at a time. Each section is normally processed by 3 routines: Carry, Tempo, and Sort.
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.
Three additional features are available for p2 alone: +, ^+x, and ^-x. 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 . + i
will result in
i1 0 .5 100 i1 .5 .5 100 i1 1 .5 100
The symbols ^+x and ^-x determine the current p2 by adding or subtracting, respectively, the value of x from the preceding p2. These may be used in p2 only and are not carried like the + symbol. Note also that there should be no spaces following the ^, the +, or the - parts of these symbols -- the number must come directly after as in ^+2.3. If the example above had been
i1 0 .5 100 i . ^+1 i . ^+1
the result would instead be
i1 0 .5 100 i1 1 .5 100 i1 2 .5 100
The Carry feature should be used liberally. Its use, especially in large scores, can greatly reduce input typing and will simplify later changes.
There can sometimes be circumstances where you do not want "missing" pfields after the last one entered to be implicitly carried. An example would be an instrument that is designed to take a variable number of pfields. Beginning with Csound 5.08, you can prevent the implicit carrying of pfields at the end of an i statement by using the symbol ! (called the "no-carry symbol"). The ! must appear at the end of an i statement and it cannot be used in p1, p2, or p3, since these pfields are required. Here is an example:
i1 0 .5 100 i . + i . . . ! i
This score would be interpreted as
i1 0 .5 100 i1 .5 .5 100 i1 1 .5 ; no p4 i1 1.5 .5 ; only p1 to p3 are carried here
This operation time warps a score section according to the information in a t statement. The tempo operation converts p2 (and, for i statements, p3) from original beats into real seconds, since those are the units required by the orchestra. After time warping, score files will be seen to have orchestra-readable format demonstrated by the following:
i p1 p2beats p2seconds p3beats p3seconds p4 p5 ....
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.
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. User-written 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.