[chuck-users] other ways to live-code with time

[Kassen]

Tom;

> I assumed from the model that the reason "now" could change was that
> user code could be pre-empted to make framerate and sample rate
> deadlines. I also assumed that loading a WAV file is a lot more about
> waiting on the disk than the CPU. I could be wrong on both counts..

That would be a interesting strategy and indeed quite clever though
the price is of course that accuracy might be lost. It's not clear to
me from that tutorial how Impromptu deals with concurrency and race
conditions and so on. Maybe I need to read it again with more care.

I also found it interesting to see Impromptu's strategy of using
slightly different code depending on the accuracy needed as compared
to ChucK's way of always having extreme accuracy at the expense of cpu
load and potential glitches.


Another interesting contrast is how Impromptu uses plugins for the
sound generation. I don't think that would be as satisfying to me as
writing my own ways of creating sounds but it does make a lot of sense
in a livecoding environment where the focus might be on the generation
of music more than on the technique on a sonological level.

> I can see why it would be nice, even though I don't need it. ;p A lot
> of rehearsal time in PLOrk this past semester was dedicated to
> synchronizing the performers because we lacked good network
> synchronization. So having NetClock as an option would have been
> great.

Was that using a wireless network? I'm not sure how the jitter of a
wireless network would affect the timeserver protocols NetClock needs
to sync the computer clocks. There has been some talk about that on
the NetClock list but I'm not sure any conclusions have been reached.
I could ask if it's relevant to you.

Anyway, I do kinda "need" this, livecoding jams across ChucK, SC and
PD would make me very happy :¬). Now that I think of it; beyond
NetClock there might be questions along the lines of Hans's recent
inquiries on how OSC timestamps would interact with the ChucK
Shreduler. I could imagine a implementation where OSC messages with
timestamps could be used to schedule commands without the need for a
shred per command.

Yours,
Kas.