I’m not sure whether the over-the-Internet performance is described in the proceedings, but it looks like an interesting read regardless:
from Jascha via Facebook:
Most people do some version of what I also wound up doing with LANdini: use a version of Cristian’s Algorithm to synchronize clock-time across many users, and use the newly formed common time to set up synchronized events in “the future”. Good examples that I’ve read about (but haven’t used) include ESP Grid by David Ogborn, and the software built by Glitch Litch for their performances.
For actual plain-old-latency issues, you’re kind of stuck with whatever latency your system has: going over various wifi routers is going to have more latency than going over wired ethernet connections, and doing stuff around the world obviously will have even more. On the software side, the best I’ve seen people do is set up a common clock-time and hang everything off that.
1 Like
Glitch Lich’s software (OSCthulu) and LANdini offer very different approaches.
LANdini: a networking utility for wireless LAN-based laptop ensembles
http://jaschanarveson.com/pages/code.html
2.1 Pre-existing solutions
There are other laptop ensembles who have also worked on solutions. One prominent example is OSCthulhu [5], a similarly motivated application developed by the group Glitch Lich (in particular Curtis McKinney). Its absence of clear documentation was an initial hurdle in its being adopted, but it also focussed on a state-based model of information flow which we didn’t feel drawn to, and lacked some of the features which we envisioned, such as the “stage map” feature (see section 3.8).
Neil Cosgrove’s LNX Studio [6] is quite a different type of application, being a collaborative music making environment that can work over LANs and internet connections. It’s extremely well implemented, but it isn’t designed to be a networking utility. What it does have is an impressively resilient network sync and message delivery system and excellent network time synchronization. It also boasts admirably open source code, and many of the features of LANdini were the result of studying and adapting solutions that were used in LNX Studio.
Ross Bencina’s OSCGroups [7] is a core component of LNX Studio, but in that context is used for internet connections, which it was primarily designed for. Neil Cosgrove’s code for LAN connections uses classes of his own making which feature the same API. Since the authors of this paper are interested in LAN-based music, we elected to follow Neil Cosgrove’s example and implement our own solutions, leaving OSCGroups to those who are working over internet connections.
OSCthulhu: Applying Video Game State-based Synchronization To Network Computer Music
http://www.chadmckinneyaudio.com/WP-Content/resources/papers/OSCthulhuICMC2012.pdf
In this paper we present a new control-data synchronization system for real-time network music performance named OSCthulhu. This system is inspired by the networking mechanics found in multiplayer video games which represent data as a state that may be synchronized across several clients using a hub-based server. This paper demonstrates how previous musical networking systems predicated upon UDP transmission are unreliable on the open internet. Although UDP is preferable to TCP for transmitting musical gestures, we will show that it is not sufficient for transmitting control data reliably across consumer grade networks.
This paper also exhibits that state-synchronization techniques developed for multiplayer video games are aptly suited for network music environments. To illustrate this, a test was conducted that establishes the difference in divergence between two nodes using OscGroups, a popular networking application, versus two nodes using OSCthulhu over a three minute time-span. The test results conclude that OSCthulhu is 31% less divergent than OscGroups, with an average of 2% divergence. This paper concludes with a review of future work to be conducted.
And then there’s:
ESPGrid
http://esp.mcmaster.ca/?page_id=1759
EspGrid is a protocol/application developed to streamline the sharing of timing, beats and code in participatory electronic ensembles, such as laptop orchestras. EspGrid has been developed and tested in the busy rehearsal and performance environment of McMaster University’s Cybernetic Orchestra, during the project “Scalable, Collective Traditions of Electronic Sound Performance” supported by Canada’s Social Sciences and Humanities Research Council (SSHRC), and the Arts Research Board of McMaster University.
Edit:
Biggest contrast between LANdini and OSCthulu is that OSCthulu requires data to be shared in a very specific format:
The core of OSCthulhu is the way it represents data, which is very similar in approach as the GCSM. Data is represented in the system as a series of networked entities called Syn-cObjects. These SyncObjects contain an arbitrary amount of modifiable values, called SyncArguments. SyncArgu-ments may be Strings, Integers, Floats, or Doubles.
Whereas with LANdini:
In order to facilitate the updating of old pieces and the happy adoption of LANdini in to new pieces, we wanted to change as little as possible about the way OSC messages were sent and received by composers’ patches.
Incoming OSC messages are, from the perspective of the receiving patch, completely unchanged, requiring no up-dating in the composer’s code.
Outgoing OSC messages are sent through LANdini and are simply prefaced with two extra strings: a protocol and a destination. The protocol tells LANdini how to send the message, and the destination tells LANdini where to send the message. Other outgoing OSC messages are sent to LANdini to request specific information, like the current network time or user list.
Another big difference is OSCthulu’s client/server nature, where LANdini makes no client/server distinction.
The McKinney brothers describe in the OSCthulu a method for measuring “divergence” in OSC state between various clients in a network music scenario. They used it to compare OSCgroups to OSCthulu. It would be interesting to repeat their test to compare divergence characteristics between LANdini and OSCthulu.
1 Like
for what its worth, i’ve been having to do very similar stuff recently for a work project. (synchronous video with networked frame clocks.)
in a simple LAN setup where everyone is running a lightweight linux, latency is hardly an issue, consistently < 0.5ms roundtrip between any two clients.
with more latency, some variant of cristian’s algo (as in the paper linked above) becomes mandatory. in a nutshell, given a master clock and some clients:
- server pings client
- client sends its local time
- server records client time and round-trip latency
- steps 1-3 are repeated some number of times, and some form of statistical analysis is performed. (raw mean is not great; long latency tends to come in spikes.)
- now the server has a good idea of both the latency, and the difference between server and master local clocks. it can report these findings back to the client.
- repeat 1-5 for all clients.
- now we know the worst-case latency and the specific latency for each client, so we can start a master clock and each client adds whatever delay it needs to be in sync with the slowest client.
5 Likes
Online Jamming and Concert Technology
Free web course
Today’s vast amount of streaming and video conferencing on the Internet lacks one aspect of musical fun and that’s what this course is about: high-quality, near-synchronous musical collaboration. Under the right conditions, the Internet can be used for ultra-low-latency, uncompressed sound transmission. The course teaches open-source (free) techniques for setting up city-to-city studio-to-studio audio links. Distributed rehearsing, production and split ensemble concerts are the goal. Setting up such links and debugging them requires knowledge of network protocols, network audio issues and some ear training.
schedule
Course opens April 19, 2016
Session 1: Overview (April 19, 2016)
Overview of Online Jamming and Concert Technology
Session 2: Basics and Setup (May 3, 2016)
Basics: Network protocols, audio signals + soundcards and network audio.
Session 3: Jacktrip Application + Connection (May 17, 2016)
Things that go wrong with Jacktrip: Network & Audio. P2P Sessions and Multi-site setups.
Session 4: Debugging (May 31, 2016)
Debug examples of typical problems.
Session 5: Polish and Practice (June 14, 2016)
Polish techniques and spawn more practice sessions.
Session 6: Future (June 28, 2016)
Future of the art and practice of network audio, alternative platforms for network audio.
2 Likes
Artsmesh project is going well: http://artsmesh.com
Graphic interface for P2P collaboration with jack/jacktrip, oscgroups, syphon/ffmpeg, chat, network tools, gnu social federated blog, router circle, video/audio mixer, live stream to Youtube, sync metronome/clocks with osc, score following, user/group profiles, world map of live streaming users, IPV6 enabled.
Pro-Presence Engineering Tool for Live Network Music Performance
Always willing to Skype with people to get them up and running.
Ken
2 Likes
hasn’t anyone invented the ansible yet?? i thought this was the future. 
1 Like
I’ve been working through the Online Jamming class on Kadenze, the instructor is a bit difficult and the classes seem to be presented out of order, but there’s some good info there.
I’ve been able to connect with a friend about 70miles away and the latency seemed minimal, though the quality of connection was awful. Still troubleshooting, but could be promising.
1 Like
Really happy to see activity on this thread. Gonna try to find some time this weekend for testing.
Hmm. I’m on OS X 10.11.4
I’m getting curious about netpd:
2 Likes
Finally had my first NINJAM experience last night, thanks to @pirxthepilot, @mzero, @bellyfullofstars, and @ikjoyce.
Somehow, after a long week of work, I managed to hang in there for 4 hours straight (and I’m not generally a night owl at all). Wow. What an experience! Not only did it work, it worked way beyond my wildest expectations. All I can think now is “when do we do it again?!”
We had a bit of client-side trouble at first. Next time I’m going to try this plugin:
http://jamtaba-music-web-site.appspot.com
The setup that worked for most of us last night was to play through Reaper, which has native NINJAM support. That worked perfectly for NINJAM, but it introduced a new, and somewhat unfamiliar DAW, which wasn’t ideal. I think JamTaba might allow us to use our usual environments.
The diversity of instrumentation between the five of us was one of the best parts. Huge variety of analog, digital, and even acoustic instruments. I can’t think of any other network music approach that would allow for all that.
5 Likes
A jamming tip for the music theory impaired, from Ethan Hein’s latest blog post:
… the D minor pentatonic scale, and that scale turns out to fit fairly well over most current pop songs. If it doesn’t, some other minor pentatonic scale is very likely to work. This is due to a music-theoretical quirk of the pentatonic scale: it happens to share pitches with many other commonly-used scales and chords. As long as the root is somewhere within the key, the minor pentatonic will sound fine. For example, in C major:
C minor pentatonic sounds like C blues
D minor pentatonic sounds like Csus4
E minor pentatonic sounds like Cmaj7
F minor pentatonic sounds like C natural minor
G minor pentatonic sounds like C7sus4
A minor pentatonic is the same as C major pentatonic
B minor pentatonic sounds like C Lydian mode
Last night we seemed to settle on F minor. 
1 Like
Dunno if this is the right place to ask… Here goes, anyway! Is there a standard way to ‘broadcast’ OSC messages? Here’s what I’m trying to do:
- make the unused ‘f keys’ on my linux laptop somehow broadcast the fact that they’ve been pressed (probably by customising dwm, my window manager)
- be able to create a puredata object with appropriate args… eg 'msg-subscribe <host> <port> /f1`
- when I hit f1 key from any virtual desktop that puredata object emits a bang
- my other application can ‘subscribe’ to the same key if it so chooses
- I could reuse the methodology to, for example, broadcast a global clock signal to all ‘listening’ applications without knowing the port of their listening server (or even what machine they might be on)
I feel like UDP multicast doesn’t actually enable this, and I need to reach for some esoteric network library, e.g nanomsg.
On the other hand, I could just copy the ‘focus-snatching’ pattern from serialosc - not quite what I want, though. Seems to me there must be an easy way to do this, and that I’m ignorant of some really important standard technology!
OSC messages can use UDP or TCP transports. Discovery is via Zeroconf/Bonjour. On Linux that is handled by Avahi.
More clues:
http://opensoundcontrol.org/discovery-osc-clients-and-servers-local-network
So in practice as I understand it, the ‘standard’ way to achieve my goal is:
- have dwm periodically poll avahi to refresh it’s list of all applications interested in my ‘f keys’
- maintain a list of receiver ports inside my window manager ‘plugin’
- explicitly send a UDP message to all of the subscribing ports
This just seems so terrible I was convinced it couldn’t be the case! I might have a very quick exploratory hack with nanomsg, pd & dwm just out of curiosity…
1 Like
maybe UDP broadcast address would help?
and if you can use nanomsg in every component there is builtin pubsub which i guess is built onUDP multicasting somehow? (i’m not very smart about this stuff)
1 Like
OSC is a pretty great protocol (very flexible and expressive, far more so than MIDI), but it does sound like the networking layer could use some work.
to be clear: there is no networking layer in the OSC spec. though it’s often referred to as a protocol it is really a data format, more analogous to JSON or protobufs than to, i dunno, TCP or CAN. it is just as likely to be used on a serial stream as anything else.
that said, the 1.1 spec from 2009/2012 does have some strong recommendations for delivery specifications (in a nutshell, use SLIP with double-END on streaming transports) and for integration with discovery services. e.g. an example DNS-SD/zeroconf listing:
_osc._tcp.localhost:5000
txtvers=1
version=1.1
framing=slip
uri=http://myapp.com/
types=ifsbhdu
i dunno, seems pretty complete for the goals of the project (which doesn’t include, for example, explicit mechanisms for clock sync, besides the timestamping itself…)
that was super easy - nanomsg is my new favourite thing! if anyone’s interested…
3 Likes