Presets - how to tips?

[thetechnobear]

anyone got any tips on how to get the presets working correctly?

i know the basics, add parameter to preset list, then click on EDIT number or RECALL number to recall.

I assume the the process is when you use EDIT and the number is highlighted then thats going to store on that preset.
I tried when Live and not Live.

but for me it appears to 'randomly' work or not work
I was trying to set this up for my patch in this months competition which you can find here

I added all the parameters on voice subpatch (on the top level patch) the idea was simple, flipping presets would given a different sound, and use different scales.
(I added to all 1-8 presets, but I then removed, since its wasn't working)

I had a few issues:

• sometimes the changes didn't seem to 'take'. i.e. when i switched back, they were gone
• sometimes the patch seemed to have locked the changes, so even though I was updating the parameter the sound didnt change.
• changing the OSC pitch dial, wouldn't update he 'note value'

i wondering if there are perhaps issues, or my msderstanding with the sel objects, and parent/subpatches and how presets work... pretty frustrating stuff at the moment.

[johannes]

The best way to edit a preset is through the parameter properties menu. There is a quirk in the toolbar preset edit buttons. The preset recall buttons in the toolbar are fine I believe.

[thetechnobear]

ah, but Im not sure I can get the note names to display in the properties menu - no?
also it seems that sel objects do not appear to work properly from the properties menu...
i.e. they do not recall... they seemed to sometimes work when using the EDIT menu.

I'll be honest, Id prefer a much simpler system, that felt solid... i.e. just select the preset, that does recall, then a store button to save the preset. really don't need anything more than that.

[anon5189335]

I'll be honest, Id prefer a much simpler system, that felt solid... i.e. just select the preset, that does recall, then a store button to save the preset. really don't need anything more than that.

I think also it is a bit complicated as it is now.... a preset should just be a "snapshot" of ALL parameters of a patch(that can be set while being live). Ill refer to nord g2 preset system.. You can save load with the ease of a button.. and you can also send midi CC 70, which is hardwired to controll the presets... need

[thetechnobear]

Johannes was showing me the G2 system but as he showed, its a bit different for a number of reasons, but in concept quite similar.
(Johannes, rightly isn't cloning the G2, but he does cross-check to ensure Axoloti functionality covers similar grounds)

CC70, we dont want to start 'hardwiring' CC or other midi messages, Axoloti has a lot of different uses, and whilst this might be great for one set of users, it may cause difficulties for others.

(personally Id hate a seemingly random CC doing some behaviour which alters my patch, which I didnt ask for... and I could envisage getting support requests, saying they've connect a controller and every now and then the sound changes unexpectedly... and then finding it was the controller sending CC70 for some reason or another)

I think its much better to provide the tools to be allow this to be possible, and make it explicit.
In axoloti this is now 'trivial'
just create a patch with a midi/in/cc i (70) and link it to the patch/preset object - then save as a AXS, and include in your 'controller object'

looking at the new Organelle, its has an interesting approach, it does respond to things like program change messages to change patches, but it also explicitly allows this to be turned off...
Id be happy with the organelle approach

or the approach we have (with controller objects) where you can just link in functionality you want.. perhaps we should have a 'controller/G2' object which has these 'default midi behaviours' for those that want it.

(probably worth remember the organelle/g2 have a small advantage that it has a display, so its easier to provide feedback, its likely we will do something similar once there is an axoloti remote!)

[anon5189335]

No for sure, no need to clone the g2 Actually since I got Axoloti I havent really used G2... Axoloti can do sooo many things G2 cant... I was just refering to G2 as one of the closest similar systems, that really functions well.. THere are probably other ways to do it , that works just as well

I think hardwiring preset change is also not desirable. Better leave it up to the user to assign it to what he wants. Just saying how G2 works I like freedom better

[pmj]

just create a patch with a midi/in/cc i (70) and link it to the patch/preset object - then save as a AXS, and include in your 'controller object'

I've just tried these steps and can't get the preset to change when I send a CC message. Is there a specific value that patch/preset needs to receive in order to recall a preset? Does a CC message of "1" load preset 1 and so on?

[anon5189335]

Are the presets you are trying to recall from a subpatch or from the main patch?

If from the subpatch the preset object has to be in subpatch.

If from the main patch, the preset object also has to be in the main patch.

Also did you connect the setup like this?:

Then just assign the radio to what midi cc you'd like to use. I think that would work

[thetechnobear]

should be ok, try this patch....

presetviacc.axp (2.9 KB)

this receives the CC via the internal midi bus, but as you can see changes the dial_1, which has presets stored on it.
(the maths on the right is just to bring dial p into the 0..127 range ... ie. the cc values you would expect)

(just for fun, I reflected the CC out of the axoloti, and then back in and it worked... so no issues with the external midi parsing )

BTW: you should try your patch outside of a controller script first, for testing purposes... so you can debug it.

[pmj]

Are the presets you are trying to recall from a subpatch or from the main patch?

Well, was trying to get it working from the controller object

Thanks for the layout pic though, very helpful. Works fine in a patch (or subpatch)

Thanks for the patch @thetechnobear - this works in a patch but I can't get it to work from my controller object, which looks like this now:

So I have your patch stored as a subpatch (which I think is the instruction from your earlier post). I upload my patch with the presets to SDCard start but no preset changes from my chosen CC knob when I restart the Axoloti.

Am I still missing something noob?

[anon5189335]

Are you sure that controller object is set up right?

This thread explains pretty well how to set up the controller object:

How to use controller object?

Hey [:smile:] Yesterday I was trying to set up a controller object to pass audio through Axoloti. I want to connect output of one Axoloti to input of another and just pass the audio through. I tried putting the subpatch on the sd-card, in the root and name it "InOut.axs". And then I entered this into the controller object preferences to call it up: "cardname/InOut.axs". But no luck. I tried with a regular .axp patch too, but that didnt work either. I also tried just entering "/InOut.axs" in…

[thetechnobear]

ok, the issue is the patch/preset object... it will only update presets in the current patch, which in your case is the controller sub patch.

no problem we can work around this.... by creating a special version of the preset object

first start with the following in your controller object (not in a subpatch as you had it)

now ((I'm assuming your using 1.0.9!)
a) select patch/preset
b) choose convert to embedded object
(we are going to make a custom object, which will work on the root patch!)
c) in the k-rate code you will see

  if ((inlet_trig>0) && !ntrig) {parent->ApplyPreset(inlet_preset) ; ntrig=1;}
  else if (!(inlet_trig>0)) ntrig=0;

change this to:

  if ((inlet_trig>0) && !ntrig) {parent->parent->ApplyPreset(inlet_preset) ; ntrig=1;}
  else if (!(inlet_trig>0)) ntrig=0;

you can see I've added an extra parent->

if ((inlet_trig>0) && !ntrig) {parent->parent->ApplyPreset(inlet_preset) ; ntrig=1;}

what this does, is say don't work on the parent of this object (patcher/preset) , which would be the controller subpatch, but work on the controller subpatch parent... which is the 'root patch' i.e your top level patch.

Ive tested this and it works

[pmj]

That works!

Also using the logic/countersat2 object and assigning one CC for increments and another for decrements works too (although doing this on a momentary switch press gives two messages out - one on, one off).

Excellent though, thanks!

[pmj]

what this does, is say don't work on the parent of this object (patcher/preset) , which would be the controller subpatch, but work on the controller subpatch parent... which is the 'root patch' i.e your top level patch.

Could something similar to this tweak be applied to the patch/load object? If so, it would mean you could use CC info to make program changes from the top level, rather than having to use specific Program Change MIDI commands.

[thetechnobear]

not quite sure what you mean...

but I think not, the issue with your wanting to just go up and down, is that you cannot retain state when loading a new patch... so you if you have an index that says your on patch 3, when change patch, it doesnt know its 4 (or 2) . the only way to solve this is to have something that retains state....

as I've suggested many times before, one way to do this would be use the SDCard file systems, and to know the patch name, the later means you have 'state', so you could go forward/backward alphabetically through the filesystem... needs a custom object. but not very difficult to write.
(oh, and I think the firmware needs an update, so that it knows the current patch name)