-- | This chapter explains some limitations and hack-features of library. -- -- -- * Prev : "CsoundExpr.Tutorial.Orchestra" -- -- * Next : module CsoundExpr.Tutorial.Limits ( -- * 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. -} ) where