I do live coding, although my style is experimental

I think experimental comes with the territory. I submitted a suggestion via the CFP for an idea of curating Clojure-made tracks instead of a real-time algorave. More like a DJ set (or mixtape) from community submissions. I think this would be a low pressure way of doing it and letting lots of people participate. I reckon there would be a lot of people sitting on tracks that they are maybe too embarrassed to share but it would be really fun to have a showcase of these and it could be done in a way where even experimental and amateur tracks are welcome. I know some of the Clojure core contributors are secret musicians and it would be super cool to hear some of that music.

Live algorave would be cool too though I'm conscious the A/V requirements may be onerous for the organizers.

A/V should be fine. I was considering maybe inviting this person https://pulusound.fi/ . She does pretty cool stuff with supercollider.

Or Sam Aaron, who would I suppose be doing Sonic pi. But maybe we can convince him to dust off some of his overtone code :)

There are a lot of livecoding and algorave people on the TOPLAP Discord too.

usually suynths redefine fine for me. but, Im using cider, and I notice I must go to the end of the defsynth and eval it, c-m-x in the middle of the defsynth doesnt work for med

I use cider as well, so the defaults redefine ok for you? The body redefinition works, but not when I modify some defaults only

ok, i havent thought about it. Im not in a position to test atm, can test later

There's some weird hidden feature there with atoms, I think it's kind of intentional but also often not helpful.

I'll try to better write up how that works

Thanks, Arne o/ Yeah, I saw something like that, hopefully it will be just to improve the cache invalidation 🙏 Will take a look during the weekend as well

The main use case I think is hooking up external controllers, you can change the values in these atoms with a controller, any subsequent notes will use the values in the atoms, and these survive a redefining of the synth. So the value you set using the controller persists instead of resetting to default. That can be quite useful which is why I think it's intentional.

But if you're not using any sort of gui or midi controller then that's not useful and you probably generally want to change the defaults even you redefine a synth.

I'm thinking it could instead be either opt-in behavior, opt-out behavior, or something that only happens if the value has changed between two calls to defsynth.

Thanks, Arne! Yeah, it seems that opt-in may be less surprising as it would follow the hot reload model of Clojure, but up to you if you think that people are relying on it somehow for some external HW o/

Yeah, I also have that issue. Guess it hasn’t affected me that much, though, as I had forgotten about it, until now. But I can imagine live coding situations where one would want to manipulate the defaults instead of every instance of a synth, so someway to opt-in would be nice. Perhaps something like: (defsynth my-synth ^:reset [arg1 1] …)

Nice, thanks for testing o/ Yeah, I would prefer it to be the default as it would be more in line with the Clojure model, but it’s ok if we want it opt-in as well

Actually I agree with you, it’s a good point to have a default that is in line with the logic of the language itself.

You can also use “synth-load”, which seems better after all (I wouldn’t have created the macro nowadays)