Yes, but on the plus side, I got to sleep, which I somehow can only do
when I hit an intractable problem.
Ah, well, for a modest fee a slower response time could be arranged as well. Think of the time you will be able to use to digest dinner, perhaps even see your family and friends! Act now! :-p
The object thing makes much more sense now. I tell all my friends to
join the chuck list, and I think they did but I've never seen one ask
a question. I think they were angry about overloading the => operator
or something. Who knows why. Anyway, I'll ask something again around 1
a.m. tonight probably, so get ready. Thanks again,
They were angry about the operator overloading? I never saw anyone respond like that. Actually I find it quite remarkable how people that I explain ChucK to tend to grasp quite intuitively what's going on as all the uses seem conceptually related. In fact people often seem to desire *more* overloading as the concept seems so general. Admittedly I never use the word "overloading" in those situations to avoid overloading my audience with information, they typically are more interested in working with sound than in being able to talk to CS vocabulary.
Oh, well. If your friends would define this;
fun void wait (dur arg) { arg => now;}
...And a few more related functions (for stuff like setting primitive array elements), then only use the => operator like a inter-UGen patch-cable I think they will be able to get by with normal C-style function notation most of the time for nearly all common tasks. It would probably look less readable but I think you could.
It seems a bit of a non-issue to me, I've been advocating enabling users to further overload the => operator, but I'm cartainly open to hearing about any issues that this overloading might lead to.
Yours,
Kas.