Skip to content

Best Practices for Writing Csound Code

PeteCA edited this page Oct 5, 2019 · 7 revisions

This is working document to describe suggestion to write readable Csound code and keep up with good coding culture. Please feel free to edit or add more important topics

Variables, naming conventions

  • Use meaningful names for the variables, after the small letter of type, use uppercase letter and CamelCase for longer words to make it understandable
aLeft, aRight pan2 aWhiteNoise, kPanning

instead of

a1, a2 pan2 af13, kdrp
  • Use uppercase or underscore to make variable names more meaningful:
gS_files[] directory  
;; or
gSFiles[] directory

instead of

gSfiles[] directory

Suggested structure of orchestra ( - definitely a matter of discussion!)

(must be worked out better)

in order:

System constants (kr, ksmps etc)

UDO-s

Global variables

Channels

Instruments

Suggeted structure of score

?? do we need it?

Instruments and blocks

  • Use meaningful instrument names rather than numbers. You can add also a number, after the name, separated with comma, if needed

instr bell, 12 ... endin

  • transform p-field numbers into meaningful i-variables:
iMidiPitch = p4
iVolumeDb = p5
aSine poscil ampdb(iVolumeDb), mtof(iMidiPitch)

instead of

aSine poscil ampdb(p5), mtof(p4)
  • Use indentation to make blocks visible:
instr Trigger
 if ...
  do something ...
 endif
endin
  • Use User-Defined-Opcodes as much as possible.

Compare

giBeats ftgen 0, 0, 0, -1, "beats.wav", 0, 0, 0

to

giBeats loadSample("beats.wav")

where loadSample is defined as

opcode loadSample, i, S  
  S_file xin  
  iNum ftgen 0, 0, 0, -1, S_file, 0, 0, 0  
  xout iNum  
endop

etc