Yeah, I have considered the same thing, and was thinking about create two objects
i) use bank messages to switch patches
ii) use program change messages to switch presets
if you have the skills, its not too tricky to create a new axo object to do something different, essentially use the fatfs methods to query the SDCard, and then you LoadPatch.
just be careful though, as doing this 'live', query the SDCard in the audio thread, would not be a good idea, and even in a separate thread MAY cause audio artefacts.
(this is the great thing about this open environment, anyone can dig it, and contribute... and the library will build with contributions)
trying to make a patchable object though raises some interesting questions...
first is, if its an object that 'loads next patch' then it would have to exist on all patches you want to switch between. and then it would have to be implemented 'without' state (since you lose state when you load a patch) , that means it would have to go in 'alphabetic order' (ok, you can prefix with numbers to force this)
Johannes may disagree, but I don't think id want this at the firmware level... id want to tell the firmware what it should do rather than have 'default functions', I think that is the 'modular way'.
Im also going to be building this into a controller implementation...more on that later
one last thought...
I actually have added patch switching which is controlled on my eigenharp, and for that as a 'performance' side, I did not want to step through patches, I really wanted the same button to always load a certain patch,
so I would disagree that the patch/load is 'not practical', in this scenario its exactly what you want.
(it would be nice perhaps if there was a 'file selector' on the object though.)