Suggestion for more "easy assignable" presets

[jaffasplaffa]

Hey

In Axoloti editor you have 8 presets in a row on top of the editor. These are very useful and makes it easy to set up some nice presets. From 9 and up it gets a little bit harder cause you cannot assing them in the same simple way as first 8. You have to right click each parameter and assign them, etc.

Would it be possible(and make sense from a developers point of view) to expand those 8 "easy assignable" preset button to 16 for example?

To me that would be very useful.

What do you think? Maybe the space is saved for something else?

In 1.0.11 some of the space is filled up with the cable colors, but there is still room for some more presets, imo

Or maybe the easy assignable presets menu could be reconfigured to be a dropdown menu, where you select which preset you want to edit. The dropdown menu would not take a lot of screen space and could cover a much larger number of presets than 8.

@johannes @thetechnobear ?

(By easy assignable presets i mean the "edit" presets menu)

[philoop]

Would it be possible(and make sense from a developers point of view) to expand those 8 "easy assignable" preset button to 16 for example?

To me that would be very useful.

I thought about that too +1 for this

[jaffasplaffa]

Yeah presets are super great and I get stuck at 8 presets at every synth, cause from 8 and up it is a bit time consuming and a little bit more complicated to make the presets. A drop down menu for selecting which prest you edit, would be really great, imo.

[Reggie]

I like the idea of access to more presets, is it possible to pull in presets from elsewhere? Like the sd card?

[jaffasplaffa]

I like the idea of access to more presets, is it possible to pull in presets from elsewhere? Like the sd card?

I was just reading up on this today:

@DrJustice has made an object for presets too. One of the modes in the object should work well but doesnt include integer spinboxes. Another one does include the spinboxes, but that ones is dependent on how the objects are placed in the patch. Which means that if you move an object your presets wont work anymore. Those objects gives you a lot more presets, but with trade offs.

But I think if the objects using spinboxes would be assignable to presets(and midi cc), drjustice's objects would be the option I would use. But for now I use Axolotis own preset system, which is also pretty ok.

We will see what the developers think about this

DrJustice contributions

The preset manager has been updated. This new version have two new features: 1 - Saves parameters as name/value pairs [1], and so it should not be dependent on the order/placement of objects in the patch. 2 - Introduces a new attribute called "savemode". The "Global" mode allows a single preset manager to save all parameters in the patch, including all sub patches. The "SubPatch" mode works like the previous version, except for point 1 above. Edit: I just added a third save mode "SubPatchV…

[Gavin]

Don't want to sound naïve here, but I don't quite understand why presets are built in the way they are. Is it not simple to just create a "preset" style object that acts like a multiplexor for each changing value, just need to ensure the parameter is connected to an inlet. This way, the object can be modified to as big as anyone wants it ? I have already played around with some of this, seams much easier to fit in and control with my setup.

[jaffasplaffa]

Don't want to sound naïve here, but I don't quite understand why presets are built in the way they are. Is it not simple to just create a "preset" style object that acts like a multiplexor for each changing value, just need to ensure the parameter is connected to an inlet.

I think the DSP use will rise a lot if you go down that road. If you have like 20 parameters and you want to use multiplexors for each parameters, you would pretty quickly reach Axolotis boundaries. It iwll use up Axolotis CCMSram and Sram if you have to use many objects just for loading presets.

I really like drjustices preset objects but untill the the spinboxes are included in the presets AND his object no longer is denpended on objects placement, I think his objects would be the best solution. Much easier to handle.

But for now I am just using Axolotis own preset system. I am sure @thetechnobear and @johannes all ready have considered what else can be done on this side, to make the preset system more easy to use

[thetechnobear]

there has been lots of discussion on this, and in calls Ive had with @johannes we have discussed it a couple of times.

we see areas if improvements needed, and also heard the requests,

so far thoughts are..

• keep the existing approach (as its really flexible, and powerful) , but add an additional 'snapshot' style as well which saves all parameters (so more like a vst). (might ditch the term preset, so we can get a clear new terminology)
• save/load 'presets'
• all parameters types stored/recalled
• make UI more intuitive.

as has been pointed out, we need to be careful of both code size, data size, and time take to load... and also being careful of 'sound glitching', also its not like vsts which tend to just be for recall, but also the current system is more a 'performance' tool, which is why we don't want to replace it, but supplement it.

actually, the more you think about it, the more 'considerations' there are... some less obvious than others.

e.g. we have to bare in mind, for many no computer is attached, rather a controller... or there might not be an sdcard?

the other side to this, is this is dependent on the (fairly major) changes which we have discussed (in dev section) to parameters. these changes need to be done before (or alongside) the 'preset' changes as there is a dependancy.

what would be interesting is to hear users thoughts on 'use case' for parameters...
how do you actually use them?, beyond simple save and recall?
(this is probably more useful than UI representations, or low level details, which is all subject to change)

of course, we have to be realistic with expectations, all the above takes time to develop, and we have to do it at a pace that doesn't introduce a huge number of bugs. no one wants a hugely flexible system that crashes or is erratic!

[jaffasplaffa]

what would be interesting is to hear users thoughts on 'use case' for parameters...

I use them for track progression, switching preset as the track goes on. But if they were easier setting up or if another system was created, that was easier to set up, I would use them for many other purposes. In general it is just nice to have different setting available with a few click.

the current system is more a 'performance' tool, which is why we don't want to replace it, but supplement it.

Yeah it is pretty useful, I agree, but it would be super great if there was more like "total recall" system too. @DrJustice ideas on this are really good, except for some limitations like the spinboxes that are not recalled.

e.g. we have to bare in mind, for many no computer is attached, rather a controller... or there might not be an sdcard?

Sure. For this it would be a great idea to be able to recall presets using midi cc or similar.

of course, we have to be realistic with expectations, all the above takes time to develop, and we have to do it at a pace that doesn't introduce a huge number of bugs. no one wants a hugely flexible system that crashes or is erratic!

Of course. I think I just wanted to hear if you and @johannes had put more thoughts into it. Maybe some of the preset ideas, made by users, have sparkled your interest to look at it again

[thetechnobear]

Of course. I think I just wanted to hear if you and @johannes had put more thoughts into it. Maybe some of the preset ideas, made by users, have sparkled your interest to look at it again

I think there have been discussions from the beginning, (though of course user input, helps these to develop these too) , its never been lack of ideas or interest - its just some of the implications are huge, and if we do it right there are some big 'hidden benefits' that go way beyond presets....

'total recall' is not really as simple as it seems, its easy to do a simple load preset and immediately update parameters buts its not the right approach (imho) - the changes need to be 'coordinated' to deal with the fact notes may still be playing... and we don't want to go through a 'transition state' that is not intended by the user. (which a simplistic implementation would do)

(there are some really horrible 'gotchas' too, which are difficult to solve, e.g. say your preset needs a new sample loaded from the sdcard, this cannot be done at k-rate, so there needs to be some kind of delay and potentially double buffering ... which means extra memory and cpu usage)

so whilst we could have 'hacked' a solution, its better to go for the correct one, based on a new parameter design, so we don't have to re-write each time new requirements come to light.

[jaffasplaffa]

'total recall' is not really as simple as it seems, its easy to do a simple load preset and immediately update parameters buts its not the right approach (imho) - the changes need to be 'coordinated' to deal with the fact notes may still be playing... and we don't want to go through a 'transition state' that is not intended by the user. (which a simplistic implementation would do)

I'd say the way that the already present preset system is working is good, no clicking etc. what so ever when changing preset. It is just a little bit "inflexibel" when you go above preset 8. If 8 and above was as easy to dial in as 1-8 I could do with this preset system, easily. Still thinking making a drop down menu to select which preset you'd like to edit would make more presets easy accesable, with out changing the preset systems functions in general. It'll just make it way easier to use and still work as always.

About changes need to be coordinated:
I dunno, I guess it have to be tested before we know. Sometimes simple is better than complicated

(there are some really horrible 'gotchas' too, which are difficult to solve, e.g. say your preset needs a new sample loaded from the sdcard, this cannot be done at k-rate, so there needs to be some kind of delay and potentially double buffering ... which means extra memory and cpu usage)

Hm, delay on preset change. That would only be if a table needs a new sample loaded right? If not there should be no delay, right?

so whilst we could have 'hacked' a solution, its better to go for the correct one, based on a new parameter design, so we don't have to re-write each time new requirements come to light.

Yeah that would probably be great. Some parameter types could benefit from a "make over".