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>
>> SinOsc b => dac;<br>
>> { a.last(); } @=> b.freq;<br>
><br>
> Ok, this I can see. My one issue with it is a fairly big one though; this<br>
> function isn't typed.<br>
<br>
</div>What? b.freq needs a float so the expression on the left would need to<br>
return a float.<br>
<div class="im"></div></blockquote><div><br>Ok, I see. And since we are avoiding a explicit return statement The last line of the function (where a function has multiple statements) would need to return a float or compilation would fail, is that right? It does make sense in that it could work but it doesn't seem especially coherent with how normal functions work.<br>
</div><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>"___ ? ___ : ___" is conditional syntax. It's an if-statement as an<br>
expression. My lambda is like:<br>
</blockquote><div><br>Yes, I get that syntax but that's like having a separate sub-language for these things. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The idea is that it's an example of something it's unlikely one would<br>
bother writing a UGen to do, and is easier to write with lambda syntax<br>
than today's ChucK.<br>
<div class="im"></div></blockquote><div><br>That is true, probably shorter than going; "class foo extends UGen{....." connecting it and maybe also giving it a signal to start doing it's thing. For repetitive tasks it would probably get quite tedious to write but maybe these could be named and re-used as well.<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;"><div class="im"><br>
</div>Yeah, they're little UGens. That's the idea!<br>
<div class="im"></div></blockquote><div><br>Ok, yes. I could certainly see advantages to that but in general I still think extending UGen would be more useful. That seems more re-usable to me though it might also lead to more conservative and less impulsive designs.<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;">It wasn't an incredibly serious suggestion. :D<br>
</blockquote><div><br>Well, you never know and it's a interesting topic for debate. It's at least fascinating to wonder what would go wrong, where and why. Theorising over this made me marvel at how there aren't so many more things that go wrong.<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>
In ruck the lambda assignment is just that, an assignment. To<br>
"disconnect" it you set a new value.<br>
</blockquote><div><br>I do like that. It does get around a .op() for each of the (new)inputs and it seems quite coherent with seeing these connections as assignments. Also; for your strategy (unlike my own version) there wouldn't be much use to a .op() there. I think that syntax-wise there are some nice ideas here though these ideas might only start to really shine with realtime performance and a interactive interpreter. Maybe ruck could be a front-end for SC? That might work, other such front-ends have been written, though that might mean losing strong timing.<br>
<br>Yours,<br>Kas.<br></div></div><br>