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
- 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
(must be worked out better)
in order:
System constants (kr, ksmps etc)
UDO-s
Global variables
Channels
Instruments
?? do we need it?
- 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