1 / 11

Csound.

Csound. a language for describing sound. General History. . Developed by Barry Vercoe at MIT. Extended by too many people to mention. Based initially on work done by Vercoe and Max Matthews for creating music on IBM 7094 and 360 machines.

denton-vega
Download Presentation

Csound.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Csound. a language for describing sound

  2. General History. • Developed by Barry Vercoe at MIT. • Extended by too many people to mention. • Based initially on work done by Vercoe and Max Matthews for creating music on IBM 7094 and 360 machines. • These first programs were written in assembler, and CSound has retained the overall flavor of assembler code in its style. • The name CSound comes from the ‘rendterpreter’ being implemented in the C programming language.

  3. Rendterpreter? • CSound source files are interpreted, then rendered. • The language utilizes variables and function definitions that can only be evaluated at runtime, and also allows real-time interaction through MIDI; thus it is interpreted. • However, the output of CSound source files is always sound; after variables and functions are bound, the source is carried to an intermediate form, from which it is written into pulse code modulation audio data (either directly to a file or into system-specific audio API)

  4. General Structure • Every CSound program can be broken down into the orchestra file and the score file. • by convention, these use .orc and .sco extensions • the orchestra file contains all the instruments; the score file contains how and when to play them. • Each file type has a fairly well-defined structure using opcode-type primitives and methods. • For example, the orchestra header ALWAYS begins with something of the form: sr => sampling rate for audio kr => control rate ksmps => sr / kr nchlns => number of audio channels sr = 44100 kr = 4410 ksmps = 10 nchnls = 2

  5. Opcodes. • CSound modules, or opcodes, are just like assembler opcodes: a base function with white-space delimited arguments. e.g. foscil 10000 440 1 1.5 8 1 • CSound also uses ‘GEN functions’ to create datatables for opcodes; these routines generate everything from simple sines/cosines to Blackman-Harris windows, used in spectrum analysis generates a Hanning window of with max value 1. e.g. f3 0 4097 20 2 1

  6. Binding, Scoping, Parameters, Oh my... • Binding is really irrelevant in Csound; there are no procedures • Scoping: variables can be scoped either: • within a single instrument • An instrument has a block structure: instr 107 a1 oscil p4, p5, p6 out a1 endin • within a score/orchestra file combination (referred to as ‘global’) • All parameters are passed by value; the mechanism is by simply placing a numeric value or variable name in the appropriate ‘p-field’ (analogous to a register argument in assembler), e.g. p4 through p6 above. • All variables in CSound must begin with one of the letters a, d, k, i, w, x, or z. (making them feel even more like registers....)

  7. So why the hell would anyone want to go to all that trouble? • It’s free. • It’s limitless in terms of the noises one can make. • It’s available for almost every platform. • Many, many development environments are available (e.g., integration into MAX/MSP) • Online documentation is exhaustive (think: the Java API on the Sun site) • The language has had excellent longevity and keeps getting better, with a richer set of built-in features and opcodes. • Highly efficient; speed is directly related to complexity.

  8. However... • Code is not very readable / maintainable compared to most ‘real’ programming languages (it’s a lot less like spoken English) • The learning curve is pretty steep • Its control flow is fairly limited; conditionals have to be implemented in a manner somewhat akin to gates on a circuit • Aside from blatant syntax errors, debugging messages occur entirely between ears and brain.

  9. A small example. ; me999.orc ; simple buzz instrument— sr = 44100 kr = 4410 ksmps = 10 nchnls = 1 instr 109 a1 buzz p4, p5, p6, p7 out a1 endin

  10. A small example, cont. ; me999.sco – score for buzz instrument ;FUNCTION 1 USES THE GEN10 SUBROUTINE TO COMPUTE A SINE WAVE ;FUNCTION 2 USES THE GEN10 SUBROUTINE BUT SPECIFIES AMPLITUDES ;OF THE FIRST 12 PARTIALS f1 0 4096 10 1 f2 0 4096 10 1 .5 .323 .25 .3 .189 .142 .125 .111 .1 .09 .107 ;bass i109 0 0.97 1600 440 25 1 i109 1 1 1600 330 22 1 i109 2 1 1600 256 20 1 i109 3 1 1600 329.6 18 1 ;alto i109 0 0.2 1600 1245 10 1 i109 0.2 0.2 1600 627 8 1 i109 0.4 0.2 1600 568 5 1 i109 0.6 0.2 1600 660 7 1 i109 0.8 0.2 1600 1245 5 1 i109 1 0.2 1600 1345 10 1 i109 1.2 0.2 1600 727 8 1 i109 1.4 0.2 1600 668 5 1 i109 1.6 0.2 1600 660 7 1 i109 1.8 0.2 1600 1245 5 1 . . .

  11. Demos and Resources • me999.orc and me999.sco render to: me999.wav • A much bigger example: • shortyorc.txt and shortyscore.txt render to: shorty.wav • using a MIDI keyboard and controller: ambientsong.mp3 • The Csound website: www.csound.org • The Online Csound Manual: • http://www.lakewoodsound.com/csound/hypertext/manual.htm

More Related