Tom;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
</div>Like how you wrote:<br>
</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
now => time start;<br>
SinOsc a => blackhole;</blockquote><div><br>Isn't blackhole a bit of a artefact of exactly the question this discussion is hoping to help solve?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
SinOsc b => dac;<br>
{ a.last(); } @=> b.freq;</blockquote><div><br>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.<br>
<br>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.<br>
<br>Admittedly my proposal didn't allow for that either and admittedly it's member functions of type float that seem most interesting right now.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
{ now < start + 5::second ? 5 : 10 } @=> a.freq;</blockquote><div><br>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;<br><br>while( now < (start + 5::seconds) )<br>
{<br> Std.rand2(5,10) => a.freq;<br> samp => now;<br> }<br><br>...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".<br>
<br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
As long as they don't do the two things you said, change the graph or<br>
advance time, they are pretty harmless. Changing variables is<br>
legitimate as long as they're scheduled as if they were in a<br>
while(samp => now) loop.<br>
</blockquote><div><br>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?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Actually, I could imagine a pre-processor that un-anonymizes that<br>
stuff automatically. It's pretty mechanical:<br>
</blockquote><div><br>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.<br>
</div></div><br>I don't think I'm sold on this so far, sorry. It's certainly a stimulating topic for exploration though.<br><br>Yours,<br>Kas.<br>