Hi Jeff,
I'm just catching up on this very interesting thread you started.
Here's my 2c's worth for now.
To state the obvious, timing needs to be accurate, which is not true
for most computer language implementations, and is a distinguishing
feature of those environments used for live coding. An interesting
situation given that computer CPU timing is very accurate. Somewhere
up the abstraction tree, time is ignored.
As people have pointed out, there are considerations to be made about
time on a number of levels that are relevant for live coding practice,
including:
1. Audio and rhythm processes need to be synchronised but often need
to be dealt with independently at a conceptual level. Most systems
have a way of coordinating clock/sample time to beats per minute, for
example, this is critical.
2. Future commitments matter in live coding. As a result, tight timing
loops or scheduling are often used to allow flexible variation.
However, managing numerous short term commitments can be taxing on the
performer so abstractions such as loops become important, as do
facilities to withdraw events scheduled for the future.
3. I agree with Nick that there is use for both scheduled event
support (such as one off triggers and cycling callbacks) and for
score-like temporal structures that can be manipulated as patterns and
dealt with 'outside' of scheduling systems. This impacts on how time
is represented and what access the coder/language has to timing
information.
The only comment I would make about scheduling architectures, which
was at the heart of your original post, is that (having worked through
the issues along with Impromptu's design) I think that polling
systems, such as the Max metro object seem much less flexible to me
than systems where arbitrary durations can be specified. A polling
system can easily be built on top if required, and there is
significant inefficiency in sending events that may not be required.
Cheers,
Andrew Brown
Received on Fri Oct 02 2009 - 03:26:20 BST