Switching patches

[thetechnobear]

I'm not sure an 'inlet' version will work... how will you know in the patch, where you currently are within that list? we would have to have someway of also knowing 'the name' of the patch currently loaded.
(not a bad thing to have actually... perhaps useful in firmware e.g. thinking axoloti remote)

[mnskll]

the thing with the inlet version is you have to know the names of all the patches on the card you like to use, and calling it from within a patch, you know witch patch you're in. but i'ts a lot of work and it has to be done in every patch as well.
What I want to be able to do is to just fill the SD with LOTS of patches and then be able to just change among those and be able to add more patches and they would be included too.

[thetechnobear]

@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)

[mnskll]

I tried the remote and couldn't figure it out so it's nice to know that it doesn't work
the axoloti control is said to be able to switch between patches, how is that supposed to work? I suppose the remote is trying to mimic that behaviour.

[mnskll]

I'm aware that clicking through LOTS isn't practical, but say a manageable number like 15-20 and then be able to load different patches on the card at different times

[thetechnobear]

how is that supposed to work

Ive never seen it working, but from the code, it looks like when you select Load from SDCard, it should then display files on the SDCard and then you can select them.

note: I think its fair to say the Axoloti Remote, has not been completed, as obviously was more important to get Axoloti Core released, so its perhaps more a 'proof of concept' than designed to be used... and its is definitely subject to major changes.

[thetechnobear]

if you have seen my Axoloti Push project, you can see what I was hinting at, with controllers and the ability to inspect the SD Card from an object

btw: I've also fixed Axoloti Remote, so it now displays and loads patches from the SDCard.

[mnskll]

looks great, but how is it done?

[thetechnobear]

hows, what done?

the Push, I query the SD Card in C, using f_opendir and then f_readdir , use this to populate the push display, then use LoadPatch(filenam) to load the patch.
(its not code to post as an example, as the push code is a little convoluted, which makes it more complicated than it is, but its reasonably clear how to do it in the Axoloti Remote code, which is in firmware/ui.c)

its not difficult to do, but presenting it in a 'generic object' has challenges (as stated previously).

I think the key will be for the firmware to be able to report the name/patch of the patch loaded... where applicable.. (since this is only applicable if you loaded from SDCard) then we can use that as the starting point for previous/next when querying the card.

.. this way we could have an object that says
current patch is N (number) on the SD card, and load patch N. (we could also offer objects to display filename of N) , this way one could programatically use a patch to load, and if wanted that could be done by program change/bank change.... or even note number (say from a launchpad)

[mnskll]

Ok, what I'm hooping for is a method to do it in the using the GUI, my C is not that great

[sovietpop]

thetechnobear : Is the fix coming for the next version ? Just wondering.
Thanks for the great work btw.

[thetechnobear]

thetechnobear : Is the fix coming for the next version

Yes, I would assume so, along with other fixes/improvements Ive been making.

however, i don't know when @johannes will release 1.0.4, its better to batch up quite a few improvements, so users don't have to update every week - assuming there are no show-stopper issues - only critical fix I've done for 1.0.4, is for multiple boards, and no one else seems to have noticed it yet

[philoop]

nice 1.0.4 is out!! anybody ? Demo patch?

[mrdrbobo]

So I don't knwo if any progress has been made on patch switching in fw or objects.
I tried it in a lo-tech manner. I put 3 patches (pg1, pg2, pg3) on the SD-card. In each of these patches I made a small switching mechanism, connected to a hardware button PB6, like this:

Then by pushing the button I can cycle through the 3 patches. It is quite a laborious solution, but it works. See the little YT video here.

[johannes]

Here's a nice description of how it can be done currently : http://ticticelectro.com/2015/12/30/getting-started-with-axoloti/
(thanks @Abhoth!)

I'm developing more user friendly patch switching for the next release...

[mrdrbobo]

Thanks! Completely missed that preferences option.

[Mubali]

Hi there, I am a new user, just got my device a couple of days ago and was curious about trying to rig this up. I followed the instructions as well as I could and built an identical patch as what the user in the link used, but I'm a little lost about setting the controller object to the subpatch I made that allows program change to access a patch list. What do I need to enter in the controller objects preferences? Is it a path to the file? Sorry, I'm a noob, but I would love this type of functionality currently while a more elegant solution is being worked on.
Thanks for your time and patience.
If there's a place in the manual that I can read about this, it's ok to direct me there instead of typing a response.

[thetechnobear]

I've explained the controller objects a bit more here http://community.axoloti.com/t/how-to-use-controller-object/910

sorry, not in the manual, I added in 1.0.6 but have not got around to adding to manual yet.

we do need an example as well. i'll see if I can get time to do either a program change to either do preset or patch loading as an example.

(I developed and was using this for the Push objects I was working on, but have not released, hence why I didn't have an example to include with the release)

[Abhoth]

Sorry for the late answer. You have probably have it sorted by now, but yeah, I put in a relative path to the controller patch. Like this in my case: "../../../../Users/hkkdr/Documents/axolotiPatches/Controller" (where "Controller" is the name of the patch)

[thetechnobear]

I put in a relative path

Id actually recommend an absolute path for controller patches... so that regardless of patch location it will be found.
(relative will work most of the time, assuming you always put your patches in the same place, but if you start opening patches from URLs or your downloads folder it will probably fail)