Glitch Lich's software (OSCthulu) and LANdini offer very different approaches.
LANdini: a networking utility for wireless LAN-based laptop ensembles
2.1 Pre-existing solutions
There are other laptop ensembles who have also worked on solutions. One prominent example is OSCthulhu , 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 ﬂow 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  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  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
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 sufﬁcient 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 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.
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 modiﬁable 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 speciﬁc 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.