Alex;
We have a good reference implementation - the supercollider server and
> client by Jamie. My haskell and perl implementations are a bit hacky
> but work (I'm using them).
>
I glanced at the docs I'll have a more in-depth look later. One thing that
strikes me right now is that there is a concept of "beats per bar" but no
way to sync to the last or next start of a bar. We can sync to the last
metre change but there seems to be no guarantee this coincided with the
start of a bar. Is that correct? Is that the intended behaviour?
> There's confusion here though between GSoC and netclock. I see a GSoC
> application being for many project ideas of which work on netclock would
> only be one. I don't think there's any point in putting all the work in
> to an application just for netclock. We could just put the work into
> hacking on netclock ourselves.
>
There might be other incentives on the academic side. People might like to
be associated with Google or place a project that was planned anyway under
the GSoC to get some of the money that I think is involved. I'm not sure,
that aspect to it all doesn't affect me nor can I affect it.
My perspective is simply that a easy way of syncing FOSS applications would
be great fun. Maybe we could get a grant for researching how many beers the
average livecoder can have before (s)he can no longer resist the temptation
to rapid-fire random numbers at the beats-per-bar and BPM settings. I
anticipate that number will turn out to be quite a relevant factor in this
mode of performing.
Kas.
Received on Thu Mar 05 2009 - 14:40:32 GMT