ok, I'll just comment on controller objects/patches, as there seems a little misunderstanding here.
(and its not the most obvious thing to be honest 
)
so there are a a few of things to understand...
a) Axoloti can only run one patch, these are the '.bin' files
b) the running patch is in memory on the Axoloti core, and can optionally, communicate with the UI via the USB link.
c) other patches can be stored on the SDCard, and are then loaded into memory from the SDCard.
d) the Axoloti UI (on the computer) is only connected to a patch that IT sent to the Axoloti Core (via 'Live') , it cannot connect to any other patch that MAY be running/has been loaded on the Axoloti.
(there are some boring , but good reasons for this ... and may change in mid-term )
so... when you are running a patch, and you want to load another patch ... you need code in your patch to do this. (exclusion is patch banks, which uses program change messages, a new feature)
you could do this by copy n paste, your code into every patch you want to load, or including a sub patch into every patch to do this BUT that becomes tedious after a while, so i added 'controller objects' which allows an axoloti object or subpatch to be included into ever patch you compile, so you don't have to do this manually. *
this helps but still means a couple of things:
- due to (d) above, when you switch patches, the UI will disconnect, and you cannot reconnect it, (doing so would upload your current patch in the UI), but the patch WILL be running on the axoloti core.
- if you change the controller object, you have to recompile and upload the patches to the SDCard, since the 'old version' is embedded in the bin files.
- because controller objects are 'embedded' in patches, they cannot retain any state when you switch patches.
i suspect the above, are the 'causes' of your issues.
ok, this is not perfect, we know..
reconnecting UI
reconnecting the UI is probably the biggest limitation IF you use the computer to controller axoloti (with for some of us is not the case, axoloti standalone feature is a big thing)... unfortunately, this is not a 'quick' thing to implement. so in the 'plans' but not short term
patch switching
this seems a more common use-case, and perhaps could be done a little simper, and perhaps the controller object could be 'cleared up'.
the primary issue is ,as you have demonstrated, there are almost infinite ways someone may want to do this, via midi pgm changes, midi note on, gpio digital or analog.
I'll discussion with @johannes, but a couple of ideas spring to my mind...
- an object, which give access to the patch bank, with simple operations like next, previous, select N.
- consider moving controller objects 'outside' the patch, so they are somehow independent.
the first is relatively easy (I think), the second is not... so might be something to consider after this current release.
- we are considering having a piece of memory, that will be retained, when patches are switched, this will allow for an patches to retain some information. primarily designed for things like volume settings, but would also be useful for patching switching logic.
sorry the above is long, but hopefully it makes the situation clearer...
so it is possible to do what you want, with Axoloti as it is today, but you will have to account for the limitations Ive detailed...these 'drive' how to implement it.
(*) controller object, it should be recognised, this was not just introduced for patch switching, I actually introduced it, to allow for midi controllers (like the Ableton Push) to be added to all my patches, so I could do things like change parameters... patch switching was just one thing, I did with them, in that object.
