Learning About RxJS, Anyone Composed Using Reactive Principles?

Hello all,

I’ve been reading about reactive programming and the RxJS library in particular. A lot of the concepts featured have been implemented in SC and so were quite familiar: streams, pausable tasks, observing when stuff changes, broadcasting messages, and other stuff like this.

This got me thinking about composing using reactive programming principles, where you would have different streams of music/audio all observing each other for changes.

I wonder, has anybody else toyed with composing using reactive principles? I’d be fascinated to hear the results and talk more about this.

Adam

1 Like

A little. I use reactive principles for dealing with controllers (GUI/MIDI/external OSC controllers). And I have a pseudo pattern class that can take external events and feed them into a pattern.

1 Like

I will most likely be trying to implement some of these principles, alongside synthesis in audio worklet, to finish my research project over the next few months.

1 Like

Would you be able to share what kind of stuff you’re thinking of implementing specifically? This seems like a fascinating area because so much of social music seems to accord with the reactive logic of reciprocal responsiveness to streams of events in time.

I’ve been thinking of call and response and other techniques in Jazz, bluegrass and kinds of African drumming. It’d be interesting to create many virtual players who are all observing each other and are able to process and respond with their own stream to what they observe, in a kind of interconnected feedback loop of responsiveness.

yes well I am still prototyping in SuperCollider, but I think what I want to implement will try to replicate how patterns work.

this is similar to what I am working on, which is kind of linked to the idea of effective complexity, and the various ways effective complexity can gotten at.

tbh right now I’m still figuring the specifics out. I’ll post a more detailed report once I’m more settled in my approach and thinking, and I’ve got some documentation to share.

1 Like

@spacedtimed Checkout http://www.the-mandelbrots.de/

Not super familiar with their work, but as I understand it they do a lot of stuff in this kind of vein. See for example this repo: http://www.the-mandelbrots.de/

1 Like

Please do. Sounds interesting!

Thanks, it looks like they’ve got a nice set up for multiple players, although I don’t know the specifics of it. What I’m thinking about is ways to automate more musical interactions between players/live-coders.

So for example, if we had 3 SC instances, each with microphones observing the room they’re in or communicating with each other through networking, parameters like loudness, current harmonic content, rhythms and tempos. Each would then change in response to the current overall state, much like what people do when they play music together. A kind of computerised social music interaction.

1 Like

Yeah the ‘easiest’ way to do that is with composable behaviors. Conal Elliott did a lot of work with this kind of thing in Haskell. It’s not easy to pull off because time becomes a problem quite quickly - and it’s probably harder to do in a weakly typed non-lazy language like SuperCollider. Every solution has it’s flaws (with one of the biggest flaws is that most of the solutions have significant performance problems with non-trivial problems). For anything non-trivial you can also end up with having to traverse graphs to make sure there are no loops.

There’s a ton of research into this. The guy who created Elm has a pretty good talk/paper/something that surveys the state of research a few years back. Things have advanced since then, but I think mostly in areas to do with GUIs (which is an easier problem).

1 Like

Very interesting! I’ll look into composable behaviours. I’m not sure I completely understand what would be the performance problem in the kind of thing I’m thinking of, something like this seems to work rather nicely:

^ This but expanded into areas other than clocks and tempo.

Thanks for the info.

It’s fine so long as you’re doing very simple things, and none of your event streams interact. In practice what you find you want to do is compose stuff. For example - generate a new stream based upon 2 event streams (time and a controller). This seems to be (based upon what I’ve read) a hard problem to solve with various trade offs. You also need to think quite carefully about how different kinds of events interact (which is where a good type system is helpful).

I think it’s a lot easier if you have discrete events. If interested I’d look at the Elm architecture stuff. I’ve idly thought about combining that in the past.

1 Like