Bucket Brigade Singing | Hacker News Reader

Bucket Brigade Singing

jefftk.com

35 pointstelotortium13 comments

Great project! I would love to try this with some folks from the San Francisco Chantey Sing [1]. I used to go every month before COVID. Now they have restarted on Zoom but it's obviously not the same. I'd thought of trying to use something like Mumble for its low latency, but this might be even better.

[1]: https://www.nps.gov/safr/learn/historyculture/chantey-sing.h...

You're welcome to give it a try! There is only one active instance (unless you want to host your own?) but you can book some time on the calendar. [1][2]

[1] view: https://calendar.google.com/calendar/u/0/embed?src=gsc268k1l...

[2] add: send an invitation to gsc268k1lu78lbvfbhphdr0cs4@group.calendar.google.com

Where is your server physically located? I expect it might make sense for me to spin something up in the bay area.

It's not a system that works by minimizing latency, instead it works by making the latency absolutely predictable and adapting to it. While you don't want to have your server in a completely random part of the world, you also don't need to locate it for minimal ping.

The bucket brigade aspect of the setup is that each person sings a bit and then that bit of singing is passed on to the next person to sing on top of. Each person hears everyone ahead of them, and is heard by everyone after them.

I'm wondering if there's a way to extend this concept so that you could hear singers "after" you if the delay is not significant (e.g. maybe you can hear everyone within 15-30ms). That would mean the leader might not have to go it entirely alone. For example, if I ping vultr from SF I get 4ms latency (tested this a while back) meaning it would be theoretically possible to have some simultaneous singing with a low-latency server. The bucket brigade approach could then be used to extend participation to those with greater geographical distance or poor connections.

The main problem with this sort of hybrid approach is that building a system for absolutely minimizing latency vs a system for absolutely predictable latency looks very different.

For example, if you want predictable latency you use large buffers, while if you want minimal latency you use tiny ones.

I've heard good things about Jamulus[1] for low-latency playing/singing together. I know of several choirs using it for practice in COVID times.

1: https://jamulus.io/

If you would like to try it out: https://echo.jefftk.com

Ninjam might also be of interest? It works on a similar principle, but it explicitly sets the delay to an integral number of beats or bars so everyone is synchronised. It was released in 2005 and is GPL licensed.

https://en.wikipedia.org/wiki/Ninjam

https://www.cockos.com/ninjam/

Ninjam takes a different approach, were you here everyone and everyone hears you, but everyone is playing/singing along with past versions of each other. This works great for rounds, but there's an enormous amount of music that it's a poor fit for.

The approach my app takes is something that works for any piece of music, but the downside is that everyone does not get to hear everyone else.

I highly appreciate these inventive, non-commercial uses of the internet. Feels like the late 90s/early 2000s are coming back.

I'm on wifi atm, what latencies are people experiencing with this tool on hardwired home internet?

Huh, I thought this might have been about Apache/httpd

Reply on news.ycombinator.com