[chuck-users] Getting Started with ChucK

[Kassen]

Tom;


> Like how you wrote:
>

Ok, yes, I wrote that but I like the idea of assigning UGen outputs to UGen
member function inputs much better. For one thing it seems much more simple,
for another it should interact better with the UGen graph's pull-through
model and so not depend on when we start such a shred relative to where the
sample clock might be at that moment to the same degree. It seems much more
predictable and intuitive to me.


>
> now => time start;
> SinOsc a => blackhole;


Isn't blackhole a bit of a artefact of exactly the question this discussion
is hoping to help solve?


>
> SinOsc b => dac;
> { a.last(); } @=> b.freq;


Ok, this I can see. My one issue with it is a fairly big one though; this
function isn't typed. As soon as we'd get this people like you and me will
start writing spectacularly large functions with many "side effects" and it
wouldn't be clear what value is being returned.

Functions in ChucK should have a return type; so far we only considered
modulation where both the in and output were of type float but we also have
UGens with member functions of type int, string and even some arrays, I
think. By the time we have defined a type and made a return statement a lot
of the advantages to this in terseness will be lost but I don't see how we
would or could get around those. When our shiny new anonymous sample rate
functions have no clear return type the type system won't be able to check
whether a legal connection has been made.

Admittedly my proposal didn't allow for that either and admittedly it's
member functions of type float that seem most interesting right now.


>
> { now < start + 5::second ? 5 : 10 } @=> a.freq;


I'm really sorry but you utterly lost me here. This looks a bit like Lisp
without the brackets. You seem to mean something like;

while( now < (start + 5::seconds) )
  {
  Std.rand2(5,10) => a.freq;
  samp => now;
  }

...or something along those line? This does look very un-ChucKian to me,
especially the question mark which seems to imply something like "if" or
"while".

Other things that haven't been addressed yet is how and whether these
functions would self-terminate and matters like local variables to them.
IMHO the "properly extend UGen and assign those to member functions of other
UGens" strategy addresses those issues better.


>
> As long as they don't do the two things you said, change the graph or
> advance time, they are pretty harmless. Changing variables is
> legitimate as long as they're scheduled as if they were in a
> while(samp => now) loop.
>

Yes, but if we demand those aspects of anonymous functions I would say they
are starting to look suspiciously like UGens in how specialised they would
be, right?


>
> Actually, I could imagine a pre-processor that un-anonymizes that
> stuff automatically. It's pretty mechanical:
>

Yes, that's true, that could be done fairly easily, but that way there is no
way of getting rid of these modulations again from within ChucK code...
unless we allow for that with more structures, by which time it will be
significantly more expensive on the CPU than if we'd do the same thing
manually. All of those shreds from a  single file/scope could easily be
combined into a single shred, for example.

I don't think I'm sold on this so far, sorry. It's certainly a stimulating
topic for exploration though.

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