Live code collaboration during a quarantine

The equinox is still ongoing and has been fantastic… But I thought I’d start a thread to share ideas and make plans for online collaboration. Please share links to network live coding software, and ideas for how we can keep making sounds and drawing pixels together


That is a great idea, here some links (an updated by other replies):



What would work for me might be a regular schedule. Like a time/day of the week when we could agree to gather. Or a couple of times? Or monthly?

Yes. Would be up for a monthly meeting. Can be as easy as a chat room to get started. I still enjoy the equinox and made some notes on things to follow-up afterwards. Esp. new to my are the web-based collaboration tools Estuary, Flow and Troop.

@hvillase already mentioned Estuary, but I’ll share some other tools we’ve been using lately for remote jams.

Troop is a collaborative editor. Works with FoxDot, TidalCycles and SuperCollider out of the box, but can also do with any REPL interpreter.

Another one is Flok, which is very similar, but web-based, and supports multiple languages (targets) in the same session, including visual web languages like Hydra.

Compared to Estuary, the main difference is that these tools expect every client to have the languages running on their computers (that is, sound is not streamed from a server). I think the advantage is that they are much more flexible in terms of what users can do (if everyone manages to coordinate and use the same software, samples, synths and configuration).

I suppose since we are enumerating systems, I should mention that extramuros is still going too, as an early example of the “share text - render with local binaries” approach that we see in other systems. There was a paper about in ICLC 2015. I don’t actively work on it anymore but every now and then take pull requests, answer questions, etc. Because of this there are FoxDot and Sonic Pi “modes” in it now.

To correct a common misunderstanding: Estuary does not stream sound from the server. The sound and visuals are rendered locally in each browser. Each language supported in Estuary has been implemented in Haskell for the browser, and one of the main vectors of the system is implementing more languages therein. The advantage of this is - precisely - removing the need for so much software/resource deployment work (installation is pretty much the kiss of death in my view in workshop situations, and syncing complex setups is okay for very committed ensembles and individuals but not so friendly to the ephemeral jam session).

A focus of work in the next few months is systems for sharing samples, images, and videos within the ensembles. is another one that allows collaboration

I just remembered another online no-install collaborative online livecoding system (?!) that was shown at ICLC Madrid:

I heartily endorse David Ogborn’s point about not having to do installs in a workshop situation. I’ve now done two dip-your-toe-in-the-water workshops at my institution, one with Hydra and one with Estuary. Neither of these would have been in any way practicable if I had to ask people to install software on either personol or, worse, institutional machines.

Being able to share media in Estuary would be great – I don’t have any skills to contribute to such a project, but I’d be happy to help test! allows to host virtual rooms with desktop/web applications sharing

I wanted to put in “live intervallic jamming” aka ninjam. @yaxu mentioned in the chat entry that linked here that participants might also want to jam using acoustic instruments (guitar, drums … recorded by microphones). The ninjam attitude is (in my understanding) accepting latency as a reality and use this artistically. Its best explained in the wikipedia article

Community is here
The quickest way to join is via Jamtaba (*link removed, still new here)

Maybe we can explore ways to combine ninjam and livecoding more.

With very long cat (tabla + live coding), Shawn Mativetsky and I have been doing live coding + instruments remotely for about five years now. In some ways, it is like a special limit case of the ninjam approach - delaying only the live coding (and only at one site) to line up with the live performance. There’s an ICLC paper about it here:

Recently, we’ve been taking the same approach but within Estuary. I use the (um, undocumented… - I mean super secret special) Estuary terminal command !delay 4.2 (for example) to delay my own audition of Estuary’s output by 4.2 seconds (for example) to line up with the metre as perceived and sent by Shawn. (We’ve been using butt (which has support for CELT audio encoding) and icecast to get his (tabla) audio to me - while the live coding is just rendered independently by Estuary in both locations.)

Hi! I’m Ramon (aka QBRNTHSS) from Toplap Barcelona. We usually make a from scratch session the last Thursday of every month in our headquarters (a creation and artistic centre). But obviously this mont it’s gonna be impossible because of the quarantine. So we’re gonna do it online and streaming it in our Youtube channel, tomorrow at 19:00h (GMT+1):

You’re invited! Also to follow us on Youtube please!

Also because the quarantine (so that’s why I’m writing here) we’re thinking seriously to do a from scratch session online and open it to all the community (maybe with a limit of coders because we can’t organize another 3 day equinox :slight_smile:), so we keep you informed, maybe next week or the other one…

Take care and keep safe!

1 Like

One factor to be aware of for zero-install, browser-based systems: even if your server isn’t blocked in parts of the world such as mainland China, external dependencies may be blocked and prevent the site from functioning.

I had considered Estuary for a course here in Guangzhou that was forced to be online, but it doesn’t load without a VPN (and I had asked a student to try it with a different VPN, and even that failed). And it’s prohibitively difficult to set up a server for Troop or extramuros over here, so I had to abandon the live component of the class. (Maybe we’ll be back on campus in time…)

It’s quite common for developers in Western democracies to assume that everyone has access to all web components, but it isn’t true. The number of times I’ve had to wait for several minutes for a page to load because of this or that Google interface (or Twitter/FB badges)… if these aren’t necessary, drop them.


Hi James - I definitely sympathize with the situation. On the other hand, Estuary doesn’t have external components (yet) and even then you still had the problem - it’s just provided by a university server in Canada. I’m not sure as a Western-based developer there is anything I can do about that. Responsibility for that might lie on the other side of the firewall, IMHO.


Thanks for confirming that – btw I had sent browser logs to you awhile back. Did anything come of that? (Wouldn’t be surprised if they weren’t informative – but I’m very curious what might have been stopping it.)

I was only guessing about external components. I fairly commonly see google-analytics or various APIs being accessed from sites that otherwise seem pretty straightforward – I should have expected that Estuary was more carefully designed than that, though. Sorry if that came across too negatively.


@jamshark70 I didn’t actually receive any browser logs from you - would you mind resending them? Would love to see them. Also curious how responsive vs is to have some sense of whether the great firewall treats the whole subdomain badly or just our more obscure host within the subdomain. Also how easy is to reach, because I could probably put an Estuary server there if it was helpful to you (that host doesn’t have the capacity of the McMaster servers but if it’s just a few people in China using it). (I think sometimes firewalls and proxies are especially unkind to WebSockets, unfortunately, so even if straight up websites work okay, more advanced applications might not, when there is lot of redirection/indirection in the routes.)

Re-sent just now. My sent mail folder shows it on February 20 – but we were talking about other things in the same thread, so the attachment probably just not overlooked.

Also curious how responsive vs is to have some sense of whether the great firewall treats the whole subdomain badly or just our more obscure host within the subdomain.

With the VPN disabled, responds quickly. dktr0 is fast too.

The WebSockets thing seems to be a reasonable conjecture.


Hi all! I was wondering if anyone here has some experience with transmitting visuals over a network. I have used NDI in local networks which worked amazing with low latency and high quality. I sadly couldn’t get it working over internet. The only other option I can think of is streaming to youtube unlisted and then using OBS to capture the stream from the browser, convert that to a texture with syphon and include that back in my own visuals. But this feels kind of awkward.

The complete scenario would be that I can stream sound over internet to my collaborator, then she can use the sound for audio-reactive visuals coded with Hydra and send the output back to me. I can then include the visuals as a texture in my OpenGL environment to map on objects and livestream the final result. Any experience, ideas or suggestions are more then welcome. All the best, Timo


Only NDI locally too ! Let’s give it a try soon , for hydra flock works very straight forward, that would let you capture your browser instread of capturing the stream.


OBS will stream to rtmp, under custom connection. If you use something for rtmp, like nginx, you should be able to stream directly to your endpoint and cut out youtube. You can also stream to rtmp endpoints with ffmpeg and vlc I believe.

1 Like