Erik Schoster
Are there limitations to ChucK i'm not aware of that would make this impossible? Think this is a dumb idea and you've got a way better one? Lets discuss!
Well, I think this is a sort of structure we are (or should be) heading for; not he "wave" brand assuch but the musical collaboration on the code level. A issue that I see is that when you and I are editing we can only re-compile when the whole file will parse or when we can do partial re-compiles of running code. Right now we don't have partial re-compiles. What we could do (and what I suppose Google does) is making sure my edits only get added to the version that you will actually run after I marked them as "done". I still think this might well go at the expense of a real musical dialogue; when you are contemplating a generative melody while I'm editing the sound that it plays and recompiling a lot that would -currently- restart your melody so you would -because of my behaviour- only ever be able to hear the first notes of what it generates or I'd have to postpone edits to give you a chance to listen. We could get around that using static members of public classes to create system-wide events to link your melody to my sounds but that would make us end up with not much more than what we already have, combined with the ability to read eachother's code. That's looking at it purely from a livecoding perspective, or at leat a "code as music" one. There are of course also other sides, like finding anf fixing bugs others left before we ever hit a time-consuming debugging stage and educational uses. I could also see advantages with making it easier to work together without edits conflicting anf while preserving the ability to work on the same file, but I suppose that figures more heavily in a "production" environment. Just some notes, I agree the idea is exciting in general and I'd like to keep looking at how we could bend/stretch it for a musical (preferably realtime) context in particular. Yours, Kas.