This chapter explains some limitations and hack-features of library.
What can not be expressed
ids
The major benefit and major problem of csound-expression is abscense of ids for p-fields, ftables, notes and instruments.
no ids for ... means ... no
p-fields/notes - opcodes that rely on p-fields or invoke instruments
ftables - k-rate ftables
instruments - convenient way to specify order of instruments
program flow control
there is no program flow control opcodes (like if, then, goto)
Srate
i've decided to represent csound's S-rate with String
.
Signal is represented with tree and it means i can't include opcodes that produce Srate
hack-way around (what somehow can be expressed)
instrument order
Orchestra section is generated from EventList
. Different instruments
have different tree structure and one instrument's tree can't be
transformed into another one by replacing leaf-values only.
You can point to instrument by its structure. There is opcode in
CsoundExpr.Base.Header that specifies order of instruments by
list of notes. instrOrder
takes in list of notes, if instrument's
tree is equivalent to note it is placed in relation to list of notes.
There are ways to make mistake. Sometimes it's unpredictable.
In example below
q1 =/= q2
sco
contains two instruments (one with x
, and another one with cpspch x
)
osc x = oscilA [] (num 1000) x $ gen10 4096 [1] env = lineK 1 idur 0 q1 x = osc x <*> env q2 x = env <*> osc x sco1 = note 1 440 sco2 = note 1 $ cpspch 8.00 sco = fmap q1 $ sco1 +:+ sco2
I think maybe it's worthwhile to introduce some way of instrument id assignment.