[chuck-users] Getting Started with ChucK

[Kassen]

Tom;


> In ruck, I made all UGen attributes accept lambdas (anonymous
> functions), which to me seems a natural extension to ChucK, but I got
> the same response, that it wasn't very ChucK-like. What languages
> besides SC allow you to do things like this?
>
>
Lisp does and most things based on it so that includes Scheme which in turn
means Fluxus uses anonymous functions. Fluxus might be a nice system if you
want Lambda's and creative programing, it even has a (modest) extension for
sound but it's mainly OpenGL.

I too feel a Lambda operator would be pushing it, I'm not sure we need it
either.

The main issue as I see it isn't one of syntax, but one of CPU. If you do
all modulations at sample rate (as this sort of link implies) and you don't
use block processing (we don't) then there will be a big hit on the CPU so
like many systems we use rates for modulation, we just allow them to be set
in a advanced way (you could also call it a roundabout way, if you wish, but
I think there are big strengths to it). Considering that this is a fairly
common request I think we might still want to look into it once we get our
"context sensitive block processing" in place (meaning we block process
except where there are feedback loops involved).

I don't see a issue with anonymous functions in ChucK as such, aside from
how a lack of a name will make it harder to later refer to them if/when we
get around to editing running code. I could imagine this;

spork ~ {
  while(1)
    {
    foo.output() => that.input;
     ms => now;
    }
  }

That has been proposed before (I forgot by whom). It's not very useful in
how much time/code it saves but it doesn't look incoherent to me. Doesn't
look very dangerous either.

More useful to me would be this;

my_ADSR @=> my_filter.freq;

or, more generally;

my_ADSR.last() @=> my_filter.freq; //this is where the danger starts as
we'll see below

Or, making it yet more general and getting back to anonymous funtions
something like this;

{440 + my_ADSR.last() } @=> my_filter.freq;

or even to pay due to the typesystem to some small degree;

{return 440 + my_ADSR.last(); } @=> my_filter.freq;

This would create a anonymous function that would implicidly be pulled
whenever my_filter is ticked. Still seems somewhat coherent to me,
syntax-wise, but it's aproaching the edge. While it can be debated whether
any of this is "ChucKian" I do think that having the option of having the
UGen graph pull values from some type of custom structure when a given UGen
is ticked fits very harmoniously into a strongly timed paradigm. This would
very quickly lead to very big issues though; when such a structure would be
a function and this function would attempt to advance time (as funtions can)
we would have a big problem (if I were the VM I'd simply give up at that
point). Basically this is inserting code into the UGen graph which is the
very last place where we want ChucK code in a normal sense of the word as
ChucK code typically does the type of thing that we don't want done there,
like change the graph or advance time.

Maybe most coherent and safe would be allowing to extend UGen in our own
classes, then allow for assigning UGens to UGen member functions and have
those functions tick these UGens. This would mean that a custom class
extending UGen would need to have a special type of function of type float
called "tick()" and that inside of "tick()" we aren't allowed to advance
time. Also; no linking/unlinking of UGens. Probably the only calls that we
should be able to make would be to read from variables and maybe from other
UGen members because if we allow function calls those functions in turn
might try to do Bad Things. This is quite a easy place to do Bad Things in.


Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090721/587e546e/attachment.html>