QUICK-REF - CsoundManual - Top of this section - Previous - Contents - Index - Next

More advanced examples.

The following program demonstrates reading from two different input files.  The idea is to switch between two 2-section scores, and write out the interleaved sections to a single output file.
 

Finally, we show how to take a literal, uninterpreted score file and imbue it with some expressive timing changes.  The theory of composer-related metric pulses has been investigated at length by Manfred Clynes, and the following is in the spirit of his work.  The strategy here is to first create an array of new onset times for every possible sixteenth-note onset, then to index into it so as to adjust the start and duration of each note of the input score to the interpreted time-points.  This also shows how a Csound orchestra can be invoked repeatedly from a run-time score generator.
 

As stated above, the input files to Cscore may be in original or time-warped and pre-sorted form;   this modality will be preserved (section by section) in reading, processing and writing scores. Standalone processing will most often use unwarped sources and create unwarped new files.  When running from within Csound the input score will arrive already warped and sorted, and can thus be sent directly (normally section by section) to the orchestra.

A list of events can be conveyed to a Csound orchestra using lplay. There may be any number of lplay calls in a Cscore program.  Each list so conveyed can be either time-warped or not, but each list must be in strict p2-chronological order (either from presorting or using lsort).  If there is no lplay in a cscore module run from within Csound, all events written out (via putev, putstr or lput) constitute a new score, which will be sent initially to scsort then to the Csound orchestra for performance.  These can be examined in the files 'cscore.out' and 'cscore.srt'.

A standalone cscore program will normally use the put commands to write into its output file.  If a standalone Cscore program contains lplay, the events thus intended for performance will instead be printed on the console.

A note list sent by lplay for performance should be temporally distinct from subsequent note lists.  No note-end should extend past the next list's start time, since lplay will complete each list before starting the next (i.e. like a Section marker that doesn't reset local time to zero). This is important when using lgetnext() or lgetuntil() to fetch and process score segments prior to performance.


QUICK-REF - CsoundManual - Top of this section - Previous - Contents - Index - Next

HTML Csound Manual - © Jean Piché & Peter J. Nix, 1994-97