@johannes , just had an idea, which actually could solve a few things....
controller objects.
these objects would be specified in the user preferences, and would be added to all patches (at the root level) when it is compiled i.e. they are not in the patch themselves.
these objects would add default functionality for a user, so different users using different controllers but with the same patch.
the main use case though is for controllers, different users have different midi controllers, and would want to add these to all patches, but we don't them to have to add them manually into every patch and save it.
(bad for demo/contributed patches)
and actually this program change idea could be considered a small controller in this case.
of course, not being on the patch, means that they can only do operations which do not require wiring, if we consider whats going on in Axoloti Remote, that can be quite a lot....
there would be a couple of 'extras' to think about with this:
- perhaps sub-patches, should be allow as controller objects? easier for some users to create.
- can they have UI components, initially id say no... but perhaps its ok, later when we have a presentations.
@mnskll, yeah I think some kind of dynamic loading would be nice, but we need to take care with the memory/performance side of that... as i said in first post, its not that hard.
also I think you need to think the practical side of this, stepping through "LOTS of patches", one by one when you have no display is not really useful either. (lets remember Axoloti can be used without a computer), so we need to think how this would work with 'controllers' like Axoloti Remote (which as far as i can tell from the code USED to be able to browse patches, though it doesn't appear to work at the moment)