<br><br><div><span class="gmail_quote">On 11/3/07, <b class="gmail_sendername">Stephen Sinclair</b> <<a href="mailto:radarsat1@gmail.com">radarsat1@gmail.com</a>> wrote:</span><div><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>Yeah, I guess like I said it's a difficult problem to generalize.<br>Since the "control" loops in Chuck can go right down to the sample<br>level, I find the semantic difference between connecting two UGens and
<br>explicitly programming a connection in a while{} loop is actually<br>somewhat of a gray area, the difference being more implementation.</blockquote><div><br>It does make a huge difference in cpu load though and because Ugen connections are far more predictable then programmers it's easier to optimize.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For instance, the decision is usually that if you chuck, say, a SinOsc<br>to an LPF, what you are chucking is the audio signal. However, you
<br>could just as easily consider that you might want to chuck something<br>to freq(). With the fact that you can then use a while{} to modulate<br>freq() at the sample rate, you could argue that the only real<br>difference between these two operations is syntactic.
</blockquote><div><br>Yeah, I suppose... You can indeed also set the rate at which Ugens run, since that's the sample rate.... But I'd say that another major difference is that you can't modulate the VM's sample-rate while the VM is running.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But of course, that's not to say that these choices are arbitrary<br>either... Obviously they are made to maximize efficiency. Chucking
<br>something at freq() would imply a great deal of extra calculations per<br>sample.<br><br>However, maybe the answer is simply to program some extra UGens that<br>allow these kinds of connections, when they are wanted. For instance,
<br>that is why we would not want to reprogram the STK synths using Chuck,<br>and would rather keep them as UGens.</blockquote><div><br>Yes, that would be a option that would make sense. What we could also do is look for Ugens that have parameters that could be modulated at sample rate without taking a big CPU hit, I think that's basically what Dan is doing with his new sync input option for LiSa but so far we have no real syntax for chucking signals to inputs that are different from each other. I suppose Gain set to substract would be a example and so is the DAC, in a way.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think a good solution for the zipper noise problem however, aside<br>from the idea of chucking to object parameters, would be to have UGens
<br>automatically at least ramp their values, when they have been<br>modified, for some determined number of samples. (Or with a certain<br>"inertia".) This would greatly increase sound quality, imho.</blockquote>
<div><br>Hmmmm. It's not a bad idea at all but there are no free rides. LPF.freq() will still need to calculate it's coefficients every sample, as I mentioned earlier I don't think you can just ramp the individual coefficients and expect it to stay stable but perhaps there are filter designs for which that's possible?
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>well basically what I'm saying is that it would be nice to have this<br>
as an option to preserve sound quality without requiring the user to<br>run his loop at 1::samp.</blockquote><div><br>I have no real issues with running loops at 1::samp, except that it's so expensive on the CPU. Perhaps a big round of ChucK optimization would cure this but I'm also very much behind the choice to first focus on getting it all to work and only then optimize.
<br><br>Functionally speaking we can already do everything that has been mentioned, you can use Envelope to ramp for you, meaning you do need a loop at 1::samp but it can be a loop that only contains extremely simple commands. I also think it's important that choices made here would fit with the rest of the syntax.
<br><br>On the other hand; some modules, like the oscillators, already do have modulation inputs but for those a choice has to be made about the way the modulation affects the oscillator. I'm currently leaning towards extending the syntax there to enable us to use multiple modulation targets per Ugen. If we would do that, where it makes sense, this could easily be used for slides/interpolation as well by using Envelope. Doing it that way would allow the user to determine the way the interpolation works and it's shape, I like that much better then a ready-made and static solution.
<br><br>I think I'm also in favor of allowing negative targets for Envelope to ramp to. There are explicit checks in the code to prevent those but I don't quite understand why those are there.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maybe one day I'll have time to look at the Chuck code and see how<br>difficult it would be to implement.</blockquote><div><br>I think this side of ChucK borrows a lot from the STK, if you want to go there you could do far worse then starting with Perry Cook's "Real sound synthesis for interactive applications" which is both serious in purpose and friendly tone, good properties for a book on that sort of topic, IMHO.
<br> </div>I think there are some very hard choices to make here. I agree there is room for improvement but I also think there is very real danger of mucking up consistency. I hope Ge has some thoughts on this, so far his solutions are quite good and the very core of ChucK syntax *is* directed at this very issue and Gasten does have a good point in his last mail to this discussion.
<br><br>Still; thinking out loud is fun!<br><br>Yours,<br>Kas.<br><br><br></div>