James;
> 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.
>
> I have to disagree that this is an advantage. There is some amount of
> logic in making synchronized tempo work correctly, and it is nice to
> have it available and just work. "shreduling" "shreds" on a tempo
> clock instead of a sample clock is a feature that should just be added
> to Chuck.
>
>
That's one of the ways that I work in; I wrote a "clock" in ChucK that's
roughly inspired by the netclock initiative because I wanted to know what
working with that would be like. It keeps time by sending VM-wide events
that any shred can wait for, it does bar lines, quarter notes, 16th, etc.
Shreds can be synced to those and they can also change how a given kind of
note relates to the clock, for example to change 4th notes to triplets. With
a bit of cleaning up of the interface and perhaps behind-the-scenes hooks to
MIDI clock and netclock I could see something like that becoming a part of
ChucK. For one thing it's convenient and intuitive to work with in
livecoding.
My point though is that this is just one option and it's something that we
can create. If instead we'd like to base all timing on a looped recording
and would like everything to change when the recording changes that too
would be possible, that might look quite different while accomplishing much
of the same result.
I realise this is personal preference but I'm not so fond of the CSound sort
of position of telling you "this is a note", "that is a beat" and "tempo is
like such and such" (MIDI implies such ideas as well). To me those things
seem like questions to be answered by the individual composer. What's
important to me is that a language like SC or CK should give the tools
needed to intuitively express ideas on these subjects. I still can't think
of anything that we might like to do with timing that couldn't be done in
ChucK. Of course it has to be noted that if we change ideas halfway into a
project or performance then we may need to do a bit of work to adapt the
code to the new perspective but the exact same holds for anything from
sheetmusic to patching analogue modulars.
I'm not sure that answers the question?
Yours,
Kas.
Received on Sat Jan 23 2010 - 13:37:40 GMT