2009/7/21 Andrew Turley
I'm not denying the logic is there. And certainly you can do certain things in ChucK more easily that you can do them in SC. I'm just saying that if you come from SC (or CSound) there are some things in ChucK that may seem a little weird. And there might be some ways that ChucK could deal with these things. But I'm not saying that ChucK is REQUIRED to deal with them in the ways I'm talking about. I'm just throwing out ideas.
At some point a programming language's utility is measured by it's ability to provide an easy way to do a common task. So in the end it depends on what you're trying to do. If you want to modulate on UGen using some other UGens, SC gives you a fairly easy way to do this. If you want sample-level control over your audio, ChucK might offer some advantages.
Lucas, I agree that what I'm suggesting isn't necessarily in the spirit of ChucK as it is currently implemented. But imagine a situation in which the following was true: 1. Integer and Float values were objects. 2. These objects had a ".value()" method that returned the value of the object. 3. UGen objects had a ".value()" method that returned the current value of the UGen. As long as whatever you chucked to .freq had a ".value()" method, then you could do what I described. Every sample, the UGen would simply call "freq.value()" and get the current value of the frequency.
Like I said, I'm just throwing out ideas.
andy
Yep, was not my intention to talk about the design of chuck but the way the things can be done. Because that I put the examples like answers. I undestand your point, sorry if I make noise. Greetings Lucas