csound-expression-0.2.0: Csound combinator library




This chapter explains some limitations and hack-features of library.


What can not be expressed


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)


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.