James;
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.
>
>
I agree, I'd much rather create clarity so people have the info they need to
make a informed choice. Either that or drop all this nonsense and get a nice
guitar instead :-)
> 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.
>
In that case I would use events, with a central clock broadcasting them,
just like you. Maybe those weren't yet implemented at the time that you
looked into it. It's true that you can't re-schedule shreds once they have
been "schreduled" for a given time so if that's what you need it would be
better to instead make them wait for a event. Once a "Event" is
"broadcasted" all shreds waiting for it are set to run immediately, which I
think is what you are after as well.
ChucK has no build in concept of "beat", which I think is a advantage as we
get to define what a beat is to us in a given scenario. Things may still get
tricky if we'd -for example- like to make looped wave file recordings stay
in sync while tempo changes but that sort of thing is hard anywhere and we
might need to use a mixture of techniques. that's ok, as those options are
there. I could write you some example code but in practice it's really quite
straightforward and nothing very remarkable is going on.
>
> 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.
>
>
We are currently collaboratively re-writing and clarifying the manual so I
made a mental note to put this in. Tempo is a important concept and if it's
unclear to you then it will probably be unclear to others as well. I think a
lot of new users are confused about what "Events" are good for and this a
great example of something that absolutely needs them.
Lately I've been far more interested in taking "strongly timed language" to
mean a language where we can easily reason about time in intuitive and
powerful ways; it's the execution order and our convenience that really
matter. Because of the size of the blocks in which samples are handed to the
soundcard the actual "timing" is largely imaginary anyway. From a timing
perspective you could say ChucK is a great deal more accurate than to the
sample, it is actually more accurate than the timing of a modern Pentium,
which sounds good at first but once we realise exactly how silly that idea
is it exposes how much of the timing is actually completely imaginary.
I take it that we now agree?
Yours,
Kas.
Received on Fri Jan 22 2010 - 19:54:29 GMT