>> 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.
What? b.freq needs a float so the expression on the left would need to
return a float.
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.
"___ ? ___ : ___" is conditional syntax. It's an if-statement as an
expression. My lambda is like:
Yes, I get that syntax but that's like having a separate sub-language for these things.
The idea is that it's an example of something it's unlikely one would
bother writing a UGen to do, and is easier to write with lambda syntax
than today's ChucK.
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.
Yeah, they're little UGens. That's the idea!
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.
It wasn't an incredibly serious suggestion. :D
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.
In ruck the lambda assignment is just that, an assignment. To
"disconnect" it you set a new value.
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.
Yours,
Kas.