I would be bouncing up&down with happiness if we got this but there *must* be some catch. For one thing the whole "pull model" for samples would have to be re-written and we need some sort of protection against double connections to single parameters.
Max/MSP and Pd handle the double-connection problem by just adding.
"b.rate" above is probably just a single number but "my_filter.freq()" is a call to a more advanced function and running those, as we debated earlier in the topic, every sample will put a drain on the cpu and there I wonder how much cheaper a C++ implementation will be then a ChucK one.
What we could also consider is enable the chucking of signals only to those member functions that cover for simple single values (with a cast to int where needed).
Yeah, I guess like I said it's a difficult problem to generalize. Since the "control" loops in Chuck can go right down to the sample level, I find the semantic difference between connecting two UGens and explicitly programming a connection in a while{} loop is actually somewhat of a gray area, the difference being more implementation. For instance, the decision is usually that if you chuck, say, a SinOsc to an LPF, what you are chucking is the audio signal. However, you could just as easily consider that you might want to chuck something to freq(). With the fact that you can then use a while{} to modulate freq() at the sample rate, you could argue that the only real difference between these two operations is syntactic. But of course, that's not to say that these choices are arbitrary either... Obviously they are made to maximize efficiency. Chucking something at freq() would imply a great deal of extra calculations per sample. However, maybe the answer is simply to program some extra UGens that allow these kinds of connections, when they are wanted. For instance, that is why we would not want to reprogram the STK synths using Chuck, and would rather keep them as UGens. I think a good solution for the zipper noise problem however, aside from the idea of chucking to object parameters, would be to have UGens automatically at least ramp their values, when they have been modified, for some determined number of samples. (Or with a certain "inertia".) This would greatly increase sound quality, imho. I guess this inertia value would have to be variable, either globally or per-UGen or per-parameter since otherwise it might interfere with single-sample computations (since it implies a certain frequency response), but ... well basically what I'm saying is that it would be nice to have this as an option to preserve sound quality without requiring the user to run his loop at 1::samp. Maybe one day I'll have time to look at the Chuck code and see how difficult it would be to implement. cheers, Steve