It's implemented as a bit of hack modifying the core template pad.html at present, but it should be possible to port it to a standalone Etherpad plugin - I was just fighting with npm and node and require() and things I don't understand at all so took an easier way out.
Firefox's "strict" content blocking mode breaks it. Not sure why.
Worked on this a bit more today.
The "strict" content blocking thing was herring, just a regular race condition bug between etherpad startup and async barry loading. Tried to fix it by saving messages in an array that gets flushed when barry is fully loaded, but somehow something doesn't work properly and loading a pad gives the wrong sound until one of the connected clients reevaluates all the proper code. Need to look into what etherpad does with chat messages on page load, maybe its different to regular chat messages.
Made `ep_barry` into a proper etherpad plugin (no patches to core etherpad needed any more), there are some weird issues still about `node_modules` search order for `require()` which I assume are due to the plugin not being published yet and being installed with a relative path.
Added a `SR` word to the interpreter which gets the engine sample rate (which may be different for different clients) so that BAZ code can adapt gracefully and still sound the same (pitch and tempo are dependent on sample rate in typical bytebeat code). It's mutable though, so bad clients can overwrite it and mess up the whole pad for everyone. Maybe I can fix that in the engine somehow.
Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.