Patch Changes and File structure in sd card

#5

its embedded in the patch that are compiled (e.g. P0-P9 in your case), so runs on the axoloti.
(nothing can be 'stay' on the computer, as axoloti can be run completely standalone without a computer)

#6

I realized there is a flaw in my controller-object-patch, it will be stuck in a loop loading...

#7

ok… what a hard day for my little fish brain…
i finally got the sub patch made, the control object and the patch bank uploaded to axoloti

the switch does patch changes but not in for all the positions and also only when i click on the Live button does the patch change

in my original patch i watch what values gives the rotary switch at each position but in your example patch i don't know how to get all the position's values.

i quit for today, tomorrow i'll attack the beast again...
thank you very much to both of your for helping me
i see my intuitive approach is not enough to guess every complex solution i need…

#8

so the controller-object-patch doesn't realy allow to be independent from the computer, the position of the switch only changes the subpatch when i click on the LIVE button (which desingages itself imediatelly after)

for the range, the problem seem to be at the two or three steps of the extreme ends of the turn of 10 steps

if i understand your controller patch idea, it sends a + step when the resistor values increases and a - step when it decreases...

in my own previous version i analized the raw number given for each step and i used logic to compare it to a list of numbers and got good switching from each step

as i got some jitter in the input number i placed a k-filter to avoid jitter.

should i do a combination of your system and mine ?
is it possible to change bin files using the same node with file name like the one i used in my patch ? (see my previous screen capture)

#9

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 :slight_smile: )

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.

#10

When you say that patchbanks work with patch change messages it sounds as they do it "out of the box" it's a little unclear, is that correct or do I still need to patch the patch change action?

#11

Switching patches in a patch bank via midi program change still needs a "controller object".
I'm creating some examples now.

#12

ah, sorry my mistake... I thought this was in firmware. apologies for misleading.

it is better its done in a controller object as its more consistent if you want to use other things to activate the patch change.

#13

That's what I thought, just wanted it to be clear

#14

I have added an object "patch/bankindex" to obtain the index of the last loaded patch via "patch/load i"
and a few ready-made "controller objects", for version 1.0.10, you get them via "sync libraries".

  • "controller/select patch with potentiometer": connect a potentiometer to PA7 to select 16 patches
  • "controller/cycle buttons" : use switches S1/S2 to go to the next/previous patch in the patch bank
  • "controller/pgmchange" : use midi program change to load a patch

and a simple patch bank for testing, in axoloti-contrib/patches/jt/patchbank-test

Enter the name of the selected controller object in preferences, open the patch bank in axoloti-contrib/patches/jt/patchbank-test, in the patch bank window, press "Upload bank table", and "Upload" the patches one by one. Still you need a start patch: create a new (blank) patch and select "Upload to sdcard as startup".

How to use patch banks and controller object with s1 and s2 buttons
Patch changing from MIDI Program Change (help)
Rotary Switch for selecting programs
Upload patches problems
SD card and sensel morph
#15

thanks johannes
please excuse my endless confusion
i can't find your examples anywhere…
after hours i found a gitsub with the famous "contribs" files but yours contains only a grainy-table.axp… nothing about patch selecting

#16

They are not in the "contrib" section, they're in the "factory" one

#17

@uleg, first =
File - Sync Libraries
File - Reload Objects (just in case)

Works great!! thanks @johannes. I have now combined midi program change AND switches S1/S2 in a controller object :wink:

#20

I'm very happy to be able to get this to work with your examples. However, for me it seems like the Axoloti initializes 27 slots above where the patches in the Patch Index exist. I find I have to press S2 about 24 times until I get to the patches I uploaded to the Patch Index. Each time it uploads an instance of the startup patch before hitting the patch index. I wonder am I doing something wrong?
Error messages:
"patch load out-of-range 26
patch load out-of-range 25
[...]
patch load out-of-range 2"

#21

I plan to buy a pair of hexadecimal coding wheels such as Cherry coding wheels to control patch changes.

But I'm not sure it will work because of the transitions (break-before-make) that would trigger unwanted load.

#22

current workaround is using a startup patch on sdcard or in flash memory that loads the first patch

#23

Pity they don't do a gray code version.
Delaying patch loading to after the number stays the same for a dozen milliseconds should prevent unwanted patch loading caused by a glitch. But I think you will hardly notice the unwanted load.

#24

Has anybody successfully used "controller/cycle buttons" in conjunction with a gpio/out/digital, to use the S1 and S2 buttons to change patches while triggering a change on an external device? I'm attempting this with both of the commands in the Controller object. TL;DR: By using this setup, pressing S1 or S2 freezes the Axoloti and the controller.

My Teensy-based MIDI controller has a preset system for the knobs that I've set up to be divided between patches, so that each patch contains 16 of its own presets. On the Teensy, I call each set of 16 presets "banks", so patch 1 on the Axoloti is bank 1 on the Teensy, patch 2 = bank 2 etc. Note: with respects to the code, my usage of "bank" has nothing to do with MIDI banks, I just call it that.

I've tested this by trying to light up the internal LED (pin 13) on the Teensy, while cycling through patches (so I have immediate feedback), but the Axoloti freezes or at least stops producing any sound regardless of cycle buttons pressed after, and the LED on the Teensy stays stuck on high. However, lighting up the LED works just fine when "cycle bottons" isn't enabled.

If this simply doesn't work, I'll just wire a whole separate button to trigger both at the same time, S1 and S2 be damned. It just seemed like a nifty idea. Thanks!

#25

i guess axoloti has the GPIO stuck in some position because you call it right before you change patches (which actually will stop the current program and start the next one)

you could measure with a multimeter if that is true.

first lets get the patch changing on axoloti working. do you use a patchbank already? that would be the recommended way.

before you start be sure to have the controller object enabled and take each patch once Live (and save it) so that it get's compiled in. then:

-create a new patchbank
-add all your patches to it
-press "Upload bank table" -> wait for it to finish (see logs)
-select each of the patches in the window and hit "Upload" (bottom left button) -> again see logs.

you should be good to go for the axoloti part. try again with the teensy, maybe it works now?

#26

Yeah, I've been using a patch bank for switching between patches while using a start.bin patch for the startup patch. I"ve never gotten a patch bank to work on startup without a startup patch, but it's never been a problem because it works as intended that way... all except for the patch changing issue mentioned above.

I decided to go with the gpio/in/digital option using a button that's simultaneously wired to the teensy and the Axoloti. It actually works perfectly. Fortunately, there are a couple unused pins in the back of mine and this part only needs 2.

Maybe you can help me with the part that took me the longest though. Do you happen to know when a controller object is applied to a patch that is uploaded to the SD card for standalone use? I understand that if I go live with a patch in the Axoloti Patcher, the controller object is applied on compilation, but when I upload a patch bank, I use patches that I haven't compiled in the patcher for a while. When is the controller object applied to those?

The reason I ask is because you can test basically anything that you add to the controller object while the patcher is live (like if I added a bunch of potentiometers, you can test them right away by going live), but in order to test patch changes, you have to actually go to standalone mode, because switching patches doesn't work in the patcher software for obvious reasons.

And the problem with all of that is, since I don't know specifically when the controller object is applied to patches in a patch bank, if I'm trying out different methods of patch changing (like different buttons, different methods in increment/decrement, etc.), the only thing that I've found to work is wiping the whole SD card and starting over again from uploading a new patch bank, etc. Anything less than wiping the SD card and starting a new patch bank from scratch usually results in the patches retaining the controller object from the most recent patch bank upload following a full wipe of the card. That process took me all night just because of the number of steps involved.

All's well that ends well though, I'm happy with this gpio/in/digital setup.