Stakeholders / Knowledgeable people
Charles Céleste Hutchins
I'm trying to think who has an interest/knowledge of working around
the limitations of OSC and might have something to bring to a
discussion of a standard Network Music Protocol:
I'm going to invite Neil Cosgrove because of his work on LNX_Studio
and the major research he's put into dealing with varying levels of
latency.
The 80c list has been discussing a general solution for musical time
across the network because Alex McClean intends to the definitive
clock solution. This definitely has implications for us.
Some of the Modalities research is also very strongly linked to this
project, especially as shared gestural data is not very different than
gestural input data over OSC. (In one case, it's you holding your own
iPhone, in another case, it's your bandmate holding their iPhone) and
some of the solutions I've found for dealing with gestural data is
very very similar to what they're doing with Modalities. They have
not yet started working on their OSC classes, and I've asked to be
involved in that part of the project. They're on gitHub:
https://github.com/ModalityTeam
I'm undoubtedly forgetting people.
I'll post something to the Sc-list
cheers,
Les
--
Charles Céleste Hutchins
http://www.berkeleynoise.com/celesteh/podcast/
http://www.bilensemble.co.uk
nescivi
One source of inspiration is the SenseWorld DataNetwork tools that we
developed during the Sense/Stage project, which was aimed at quickly
sharing data between various programming environments (SuperCollider,
Max/MSP, Processing + Java, PureData, Python and C++ clients at the
moment available). Documentation and references to papers available at
http://docs.sensestage.eu
Another inspiration could be libmapper project at McGill University,
also meant for data exchange, but based on a peer-to-peer basis.
sincerely,
Marije
On Apr 19, 6:27 pm, Charles Céleste Hutchins <celes...@gmail.com>
wrote:
neil_c...@hotmail.com
Hello.
So I thought I would try and get down the problems i faced and how i
solved them.
LNX uses OSCGroups by Ross Bencina.
A OSCGroup Server is needed to send all the real-time messages from
one machine to another and the client pogram connects to this server.
As a user you broadcast a simple profile which you can edit. When you
connect, your profile appears in a room along with anyone else in that
same room (Rooms are equivalent to groups in OSCGroups.). Once in a
room you can chat & invite others to start a collaboration. The person
who does the invite becomes the "Host", this changes to someone else
if the host leaves.
The invite process sorts out who does and who doesn't want to be
involved in the collaboration.
Initially users are put into the same "Public" room and then have the
option to go into another room to collaborate in if they want.
There is then a handshaking phase that starts the collaboration and
works out the delta between the different machines. This is done with
100 pings which gather 3 bits of info - time sent, time received and
time returned. I then discard 50% of pings with the highest latency
and use the remaining pings to calculate the delta.
I then have various networking tools that become active. This is how
the objects talk.
LNX_Objects <--> LNX_API <--> LNX_Protocols <--> OSCGroups
You register objects with the API and expose selected methods. With
the API you can use the various tools in the protocol.
I will try and cover these tools and why I use them.
1. Normal send / delivery.
You can send messages and these can go missing. This happens a lot
more over a wireless network but can still happen if you are connected
to your router via a LAN cable.
Sometimes its important to let messages go missing.
I use this when I need the message to get there as fast as possible,
2. Guaranteed delivery.
Each user keeps a history of every message sent and received via this
method. They are numbered and everyone broadcasts the last message id
they sent (every 0.1s). If a user is missing any messages they request
it to be resent. This will increase overheads when it happens but it
Guarantees the messages get there.
Uses: Dialog / chat, sending large lists broken up into smaller
packets.
3. Ordered delivery.
The same as Guaranteed but the order the messages are sent in is
maintained. If messages arrive ahead of the order they are sent, we
wait to action them until the previous ones arrive.
Uses : Most critical system requests like... Add, delete instruments
(via host).
4. Destination. To a user, to everyone or to the host.
The host is used to make sure everything happens in the same order
5. Sent a list of any size. Large lists are split into small packets
and reassemble. Lists can be compressed to reduce network traffic.
Uses: Sending songs / presets / Piano roll data or any large list.
6. I call the below process Variable Parameter.
When a knob or slider is moved it does...
a) the slider / model is registered with a task id with the api
b) sends updates via Normal delivery to everyone. (message goes as
quickly as possible)
c) if after 0.35s of no changes, the last value is sent to the host
via ordered delivery and then the host sends this value to everyone
via ordered delivery.
This means everyone can change its value, updates are as fast as
possible and the final value will always be the same no matter how
many people interact with the value.
Normally delivery, Guaranteed delivery or order delivery are bad at
this task if used on their own.
7. Send Delta. / Group Command Sync
Schedules tasks to take place in the future (Greater than max latency)
and syncs to Common Time. Used to start clocks and tempo changes.
I'm sure there is more but thats all for now.
Problems, Additions or changes I desire.
You don't know when OSCGroups is connected to a server.
Better security. Encryption maybe?
Move some of the above tools into OSCGroups or equivalent.
Neil
Alex McLean
LNX is impressive, congrats! How tied to supercollider do you think it
is? I don't use supercollider much at the moment, but would so love
to be able to time sync with supercollider, fluxus, impromptu, chuck,
pd etc people with minimum fuss..
cheers,
alex
Juan A. Romero
> I don't use supercollider much at the moment, but would so love
> to be able to time sync with supercollider, fluxus, impromptu, chuck,
> pd etc people with minimum fuss..
Dave also asked if there is a protocol for the MandelHub/MandelClock (https://github.com/cappelnord/BenoitLib) we use. I think Patrick implemented a follower in OpenFrameworks for our visual system so it wouldn't be that hard to implement this kind of tempo followers in other systems. Our sistem has a leader who sends the sync signals, and the followers try to accomodate to that tempo. More technical details, better ask patrick, but I think it would be pretty easy to implement a listener clock on those systems if they can easily mange a tempo clock and quantisation (like everybody having the same downbeat).
Btw, our systems is thought only for local synchronising, I think Neil has a much better approach for dealing with latency and synchronising over the internet.
Als the McKinney bros. said, it all depends on the circumstance, but I agree a 'easy to sync' clock implemented on various systems would be really cool to just plug into a network and jam with the others synchronized. The other communication or value sharing tools might be another big thing... but just a synchronizable clock to gather users with PD, Chuck, Fluxus, Impromptu, etc.. would be really cool for some jam sessions. :)
Cheers,
Juan
Patrick B.
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).
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.
So long,
Patrick
On Apr 25, 10:52 am, "Juan A. Romero" <ruk...@gmail.com> wrote:
> Hi Alex,
Charles Céleste Hutchins
do, as it supports gestures, remote messaging and sending blocks of
code and things in order.
Is there documentation of the protocols? It would be nice if a server
were smart about them and handled the guaranteed delivery for you and
could work as the host.