Thanks mate... I followed all the step i found in here..
I was wondering if it possible to do the step 4 in a different manner.. or do I really have to do the naming step manually and diconnect axoloti and change the name between each save?
, yes sure would be nice if it just named next 001, 002, 003, .... it uses only 00.BIN, not 3 zeros as axoloti uses for other indexing, for the string/index for example.
Johannes has a better idea for program changes generally, that may be included in the firmware. but I'll still show this, as using controller objects is more a general purpose use-case, its not specifically for this.
Yeah please, show this if it helps 
But what is your experience? have you managed to get the controller object working? And in which scenario?
ok, Ive found the issue...
it looks like another change has been made, that means it operates a bit differently now from how it used to work, and how I described it... I will update the other thread.
now it works by explicitly loading as an object from the object path, and you cannot give it an explicit path.
so you can see Ive added /Users/kodiak/Documents/axoloti/objects to my search patch
I then have saved my controller object in
/Users/kodiak/Documents/axoloti/objects/controllers/test.axs
what seems to have changed is that we can now no longer load objects with fully qualified path names,
at this stage I'm not sure if this is a bug or not, but for the next release this is all changing anyway,
so im not going to 'loose sleep over it'
sorry, I didnt test it earlier, but not been using them since I got a Push 2, so hadn't noticed it had stopped working the way I had originally done it.
No problem Thanks for claifying it. Soo.... Create a folder and save ONLY the controller object inside that folder and refer to the folder not the patch itself. CHECK
Will see what happens down the road regarding the program change.. I dont really use it yet, but I have a friend who wants to use axoloti as part of his live set next weekend, so I promised to help him figure it out. And he got it working, so all good here
And thanks for the pic.. This helps a lot
I've updated this post, with explicit instructions
the main thing, is it has to be on the object search path, and the the 'controller object' preference is referring to an object rather than a file.
on reflection, I probably changed this later on in development, as for the Push i developed a custom axo so probably when I did that I moved away from a subpatch to a 'fully fledged' object loading, knowing I could still use AXS files if it was required to be done in 'patching language' this will actually work very nicely with the new 'user library' functionality.
Old thread, but it came in handy for me this evening and I have something to add: A small enhancement to the program loader using a 'limit' object which avoids attempts at loading a non-existent patch if the program number exceeds the number of saved patches.
Could this work with an analog control (I'm using an axocontrol board)?
The idea would be to use one of the switch to go through all patches, and to use the dedicated LED to blink according to patch number. for example when patch 1 is loaded the LED blinks one time, patch 2, twice and so on. Would this work?
I want to do this too but find the whole patch management scheme baffling to say the least.
If you don't want to mess with strings and paths you could use a patch bank (in the patcher: File > New patch bank > Add patches in the order you want them > press Upload patch bank to save it to the axoloti). Then place a "patch/load i" object in all of your patches and connect a "const/i" object selecting the next patch to be loaded and the trigger signal from your gpio button. If you need back and forth try patching something with a "mux/mux 2" object with integer inlets.
The LED indicating the patch number should be easy, but I can't figure it out somehow. Here's as far as I got:
There seems to be an offset or so, most of the time it flashes one time less than it should.
I found a way to change patches but it is very different to patch banks, but I think it is easier, but may require a little more in the setup.
Basically you have a patch just for loading other patches, a kind of master patch, but you will need to setup a trigger for every patch you want to load. But when you are done with the patch, you only need to have one object setup to return back to the master patch and the same object can be used for every other patch you intend to run.
This way you can have different master patches, and and remove patch names as required. But as said in the beginning, it is a little more work. But I like it because it feels like I have a little more control over my setup.
Thats interesting!
Could you share a patch with the explanación? I think that many axoloti users could be interested.
Patch changing its quite frustrating for begginers
OK I have tried this about 50 times.. no matter what I do I can't seem to get the following step to work..
In the connection window you will now see
start writing file to sd-card
filename on sd o:pgr00.BIN
Done writing to SD card.
All I see is :
N
Done compiling patch
Creating directory on sdcard : /NameOfMyPatch
Done creating directory
Start uploading file to sdcard : /NameOfMyPatch/patch.bin
uploading: /NameOfMyPatch/patch.bin
uploading : 100%
Done uploading file
.. what am I doing wrong ?
The message you're getting means you've successfully saved the patch to the sd card.
You can then use the patch load object with a string to load this patch. It's confusing at first...
I use a similar approach to what gavin said a couple of posts before. Works well.
I'll try and post the patches I use at some point.
Basically, I have an 'innit' patch which loads as the start up patch on my axolotis. This has patch load objects that load patches saved on the sdcard, plus midi thru and audio thru setups.
Then every patch I use has a couple of objects that respond to a midi note that re load the innit patch so I can then load another patch from it.
Had a moment to spare, here's the stuff I use.
This is the 'init' patch I use - I 'upload to sd card' and 'upload to sdcard as startup' this patch.
init malcolm upload.axp (16.3 KB)
And in every other patch I have these objects which simply reload the 'init' patch so I can select/load a different one.
init load patch.axp (2.3 KB)
Just my 2 cents,
but it might be a problem with the directory maybe? Are you running the patch in standalone mode or connected with the computer in 'live' mode?
When I'm working with samples, my samples on the SD card are read from a directory with the same name as my patch, but when I upload my patch on startup on the SDcard, it reads in the root directory... so then it doesn't find my files (which are in the directory with the name of the patch)
So it might be something like this you are experiencing perhaps? Might be a long shot but who knows 
good luck
