I agree that given Ge's goals, different choices had to be made. I
don't want to make this into a Chuck vs SC thread.
What I meant about tempo was that (at least at the time I looked at
Chuck which was admittedly early in its development) if you were to
schedule an event some time representing a certain number of beats in
the future and then later change the tempo, the time of the future
event would not automatically adjust in the proper manner. And if you
have several "shreds" running then they could get out of sync across
tempo changes. In SC, if events are scheduled on a tempo clock and the
tempo changes, even at arbitrary points between events, then events
being scheduled from different tasks will stay in sync.
I don't even find "tempo" in the Chuck manual. In the section on time
and timing, durations are only in seconds or samples. There is an
example of defining a "quarter" as fixed at half a second.
On Fri, Jan 22, 2010 at 9:48 AM, Kassen <signal.automatique_at_gmail.com> wrote:
> Yes, I read that some time ago. I don't really understand what is meant by
> "ChucK doesn't handle tempo". It's true that there is no such thing as a
> "tempo" keyword but you can certainly make ChucK deal with tempo as long as
> you can define what "tempo" means to you in a given context. There is no
> inherent concept of a "note" or of "polyphony" in ChucK either but that
> doesn't mean those aren't handled, at least not to me. What I found a bit
> surprising is the notes about how there will be audio hickups once the cpu
> is overloaded. Of course there will be; once we give the cpu too much to do
> then there will be glitches in the sound, delays to the instructions on what
> sound there should be, or both. This is the exact same for any system and we
> can make design choices that affect in what way things will go wrong when
> this happens. Clearly CK made different choices there from SC and either
> system may be seen as failing more gracefully under different conditions.
> McCartney is quite right to point out that longer computations can cause
> audio glitches but I'd say that the alternative would be to give audio
> precedence which would lead to "musical glitches" (notes that are late,
> LFO's that are slow, etc) and no mention is made here of how ChucK's
> behaviour also means that these computations may actually be doing (part of)
> the dsp themselves in ChucK, in which case we may *want* the audio to wait
> until they are done.
> To be perfectly clear; I don't disagree at all with what was written there
> but I do feel that either strategy may be preferable under some conditions.
> It's a valid point, it relates to the internal architecture of ChucK and
> it's of course always useful to contemplate such factors because knowing
> more about a system will allow us to make better use of it or predict how it
> will fail when it does but it's unclear to me why some people refer to that
> post as a clear downside to ChucK because I don't think it is. It may well
> make ChucK unsuitable for some applications but then again, other factors
> will make SuperCollider a less suitable choice.
> Much of what was said on this subject, including the linked post, was said
> before the release of Ge's thesis. This is all a bit unfortunate because it
> was only with Ge's thesis that there was a clear explanation of the internal
> workings of ChucK and the relationship between the execution order of shreds
> and the UGen graph. While I wouldn't go as far as saying that wrong claims
> have been made I think there is a lot more clarity now on how things work
> and why those choices were made.
>
--
--- james mccartney
Received on Fri Jan 22 2010 - 19:15:17 GMT