<div class="gmail_quote"><div>Hi Stephen,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">From: Stephen Tetley <<a href="mailto:stephen.tetley@gmail.com">stephen.tetley@gmail.com</a>><br>
<br>
Hi John<br>
<br>
For the user level stuff, I don't think CSound really has "functions"<br>
- either for the score or orchestra. The score I think is just a list<br>
of /notes/ with many, many parameters and the orchestra is a graph<br>
description saying how the UGens are connected. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is good news - I believe Pan, Feldspar, Lava etc. generate<br>
functions or procedures in the output code which means they have to<br>
involve the complicated techniques for embedding lambdas and functions<br>
in the EDSL. If they didn't, there would be massive code blow up.<br>
However because CSound is more or less "straight line" code - i.e.<br>
lines are interpreted sequentially, there are no procedures or<br>
functions to define and call - generating it should be much simpler.<br></blockquote><div><br></div><div>Yes, exactly. I'm not interested in anything nearly as sophisticated, so those aren't great examples for me.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Andy Gill's Dot package on Hackage has a crafty, but simple technique<br>
to allow you to reference graph nodes and link them within a monad and<br>
output as "foreign" code - here dot files. Something similar might be<br>
satisfactory for orchestra files.<br></blockquote><div><br></div><div>The orchestra graph is basically the issue I'm looking at (ignoring the score for now). My first implementation used an Orch monad very similar to the one used in Andy Gill's dotgen. It worked and the implementation was very straightforward, however I wanted to see if it was possible to create a non-monadic interface. That is, change my classes from</div>
<div><br></div><div>class GenM repr a where</div><div> sigGenM :: a -> repr (ASig repr)</div><div><br></div><div>to</div><div><br></div><div>class Gen repr a where</div><div> sigGen :: repr a -> repr (ASig repr)</div>
<div><br></div><div>This is in tagless-final style (which really is slick BTW); that's why everything is represented through type classes.</div><div><br></div><div>The second version is really the one I want to use, although it was more work to implement. For the Csound interpreter, I needed a naming mechanism like TH's Q monad, along with some other machinery.</div>
<div><br></div><div>So here's a very simple expression:</div><div><br></div><div>t1 = let v = sigGen (cnst 1) in outs v v</div><div><br></div><div>which is what led to my question. I'm binding the sigGen to 'v' to introduce sharing at the meta-level. Would it be better to introduce support for this in the dsl?</div>
<div><br></div><div>Anyway, here are a few simple test expressions to provide the flavor of what I'm doing:</div><div><br></div><div>-- additive synthesis, 20 partials of constant amplitude</div><div>t6 = let so = sum . zipWith (oscil (cnst 1000)) [ cnst (110*f) | f <- [4..]] (replicate 20 1)</div>
<div> in outs so so</div><div><br></div><div>-- stacked frequency modulation using 4 oscillators</div><div>t8 = let stack = foldr ($) (csig 40) (replicate 4 \fq -> oscil (cnst 1000) fq 1) in outs stack stack</div><div>
<br></div><div>The edsl provides the functions "oscil", "cnst", "csig", and "outs", but most of the magic happens in the csound interpreter.</div><div><br></div><div>Cheers,</div><div>
John</div></div>