Fwd: [LiGroCoP] Re: Stakeholders / Knowledgeable people

[Scott Wilson]

On 25 Apr 2012, at 11:46, "Patrick B." <pat...@borgeat.de> wrote:

After SC2012 I thought a lot about this kind of stuff. I think while

most sync implementations are based on the fact, that computers are

precise enough to keep time if they know a common start time the

MandelClock implementation is more modeled after a musician that

constantly listens to a rhythmic leader (in a band often the drummer)

and tries to keep as close as possible to him by accelerating or

deaccelerating.

While the implementation itself is a little bit clumsy and sample

precision isn't possible we get some stuff for free:

- accelerandos and ritardandos just work for free, even if they happen

a little delayed

- The system is able to recover sync if lost: I tried this case:

A(Leader) and B(Follower) were connected through ethernet cable. A and

B were in sync. Unplug cable. As all clocks are ticking locally too

they're still in sync. A does a subtle tempo change. Clocks get out of

sync. Replug Ethernet cable. B catches up and is in sync again.

- subtle async (and changing async) is musical. Imagine everybody was

sample synced and everybody would have a sharp percussive envelope on

a downbeat. The signal would clip for a short time. With a subtle

async this doesn't happen. There might be a subtle phasing that

changes all the time, because followers constantly will fall slightly

out of sync and regain sync.

So while MandelClock might be a bad technical solution it works quite

well on a musical level. But only on LAN and on decent WIFIs. This

could be improved though (currently there is no real latency

compensation).

With BEER we've been using the TelepathicClocks by Julian et al. I was very impressed with their human like behaviour in the Virtual Gamelan Project.

They can listen to a variety of other clocks and weight them, so in theory you can get very complicated behaviour, though in practice we've used them in a MandelClock way, with one master and several listeners.

I implemented a follower for a OpenFrameworks project. It has no

Scheduler but I can get the current position of the clock on every

frame.

Currently it's a little bit locked behind the whole MandelHub package,

you can't just start the clock without everything else and there is a

OSC namespace and conventions and stuff. I'm behind of documenting

stuff but if there's some interest I can extract the protocol for the

clock sync stuff and post it here, so people can think about

implementations on their system.

If you use SuperCollider the best thing atm is just to:

MandelHub.start("Jaja");

or

MandelHub.join("JuJu");

as this will set the default TempoClock to a new TempoClock instance

that is controlled (and synced) by MandelHub.

The other main feature of MandelHub is MandelSpace, a shared

dictionary/hashmap (with built in scheduling of values) for which i

want to rewrite the network part after a good talk with Neil. Finding

a standard way for doing that might be interessting as well, and be

aware, that a concept like this can easily be extended for other

purposes, as you can trigger functions on value changes, etc.

Keep in mind: MandelHub is designed for live coding, so there is no

remote method invocation system (because we don't need that) built in.

As I see it BiLETools is all about that. So we must be careful: A

common solution might not be the best for everybody and could cripple

diversity in networked laptop performances.

I think a general shared data space approach would be very useful, and I think it should be possible to do it in a fairly generic way. If you provide hooks for watcher functions then the rest becomes straightforward, or?

How do you deal with synchronisation in MandelSpace?

S.

[Patrick B.]

> I think a general shared data space approach would be very useful, and I think it should be possible to do it in a fairly generic way. If you provide hooks for watcher functions then the rest becomes straightforward, or?
>
> How do you deal with synchronisation in MandelSpace?
>
> S.

Value changes are transmitted together with the time they should take
place. You can either set the moment the value change should takes
place by a additional argument to the set method, by a Quant or if the
value is set by a pattern by a special keyword. So when a value-change-
message is received it's changed instantly if it should have already
happened or is scheduled to the future. As we consider all TempoClocks
in sync this works.

Most important: Even if their slightly out of sync at least the change
(for example: a chord change) happens on everybody's downbeat.

x[\ok].setValue(20, m.clock.beats + 10); // set 10 beats in the future
(value is transmitted asap but scheduled on the clients)

x[\ok].quant = 4
x[\ok] = 50; // value will change on the next bar
x[\ok].quant = nil; // next change will be instantly

(
Pdef(\ok).quant = 4;
Pdef(\ok, Pbind(
\type, \mandelspace,
\deltaSched, 4, // the \ok value change is scheduled 4 beats to
the future but transmitted asap
\dur, 1,
\ok, Pseq([10, 20, 30, 40], inf)
)).play;
)

[Patrick B.]

> With BEER we've been using the TelepathicClocks by Julian et al. I was very impressed with their human like behaviour in the Virtual Gamelan Project.
>
> They can listen to a variety of other clocks and weight them, so in theory you can get very complicated behaviour, though in practice we've used them in a MandelClock way, with one master and several listeners.

By the way: We tried TelepathicClocks before developing MandelClock
but it didn't really work for us (we had some weird tempo behaviour
and also some near-crash-experiences, which was a no go for a
performance system for us)

Now, almost two years later I think we could have resolved these
issues (actually I started thinking about that after I saw BEER
performing with at at NMF).

[Scott Wilson]

Yes, I think Alberto and Julian said they were in a bit of a transitional state. We had to use the example code commented in the class files to get them working, but since then they've been quite nice. I could send you some boilerplate code if you're curious.

One thing that I wanted to try was every clock listening to every other clock. It turns out that this is sort of pathological in the current implementation, and that they tend to spiral off into tempo oblivion. I talked about this a bit with them and Julian suggested that they needed to have sense of target, or I thought sort of a sense of intention. (i.e. what do we think we're doing, even if we can change our minds).

It's actually a very non-trivial problem! Since then I had a meeting with some people from the Psychology department here who have been studying this with SQs, and even in those cases (a clear leader, a known target tempo), there's a lot of research to be done in terms of how people negotiate a tempo.

Anyway, interesting stuff...

S.