Note: this is a 'pie in the sky' topic, just a discussion...
(i.e. dont get your hopes up on it being implemented )
Ive been recently playing with Extempore (http://extempore.moso.com.au), and quite like what it has to offer, and wondered how something similar might be possible be offered on the axoloti core board,
and direction we might go to add some of its ideas to axoloti.
(you could argue, SonicPi and many others offer similar... though many of these rely on Supercollider)
so there are two parts that interest me:
- hot swapping code
- other "user" interfaces
(maybe later I'll split these into two separate topics, if there is interest in discussing both)
hot swapping code
the most obvious here, is to do like (apparently) the nord modular... and allow patches to be edited live, substituting in new patches on the fly.
of course, many issues in doing this, to ensure audio is uninterrupted.
Im kind of interested in, how would this be done (approximately, I know its complicated)
what granularity is used? e.g. you could imagine, and entire patch being substituted or individual objects.
the later seems problematic, since you cannot optimise the whole code if you do this, only down to object level, and the STM32 probably needs this optimisation.
how do you keep state? a particular problem if you do an entire code swap....
does something like MCJIT with LLVM handle any of these issues?
is this all or nothing?
e.g. I was thinking of an application, where actually most of the patch is pretty static, but I should like to alter some some elements (e.g. say some calculations) ... something that requires a bit more than just changing values, e.g. introducing new calculations, but does not require changing the call hierarchy.
(random thinking: like changing a pointer to function... I just need to introduce a new function... hmm, Im thinking perhaps this is possible in a similar way to the way a patch currently works. having a special 'upload' section, and then being careful about how I switch between code i.e. you flip between an active code, and uploaded code, at a safe point e.g. next k-rate run.)
other user interfaces
initially, I was thinking about GUI vs languages (these lisp ones are quite nice).
this are interesting, for different use-cases to a graphical environment...
this one is easier to imagine applying to axoloti, and has previously been discussed a bit in this thread , the 'obvious' solution is to create a patch file, and compile it... and some clever programming/language bindings could even expose axoloti objects.
I also wondered about the 'nature' of the interaction between axoloti and a 'client computer'.
e.g. imagine axoloti hardware as been a generator (like supercollider) that is externally told what to do...
I guess this is not dissimilar to what axoloti is currently doing... which is running a patch, that its been created on the computer until is told to stop* and of course, if you have 'live coding' principles, with hot swapping of code, then that relationship between computer and axoloti becomes a more 'continuous one'
(* even running standalone is the same, at some point a computer told it what to do... its just it can carry on doing it autonomously, surviving disconnection from the computer, and even power cycles)