I think the preset system is extremely difficult to use (or maybe I just don't understand it).
Here is my proposal for a preset system that is simple and intuitive:
- All parameters should per default be controlled by presets.
- Optionally you could choose to exclude a parameter from being controlled by presets.
- If you choose to exclude a parameter, it is excluded from ALL presets.
+1 for this. I think a preset system that doesn't save all parameters, by default, at least, is indeed unintuitive. A preset system needs to allow for complete recall, and can't do that if only certain parameters are saved.
a|x
The motivation behind the "exclusive" preset system design is to save memory. I've been thinking it should be renamed to "changeset" rather than "preset".
An all-inclusive preset system takes N*P words of memory, where N is the number of presets, and P the number of parameters in a patch. A selective preset system takes N*S*2 words of memory, where S is the number of parameters affected by the change.
I believe there are many situation where an "all inclusive" preset system can be annoying, for example, if you're live tweaking a step-sequencer, you probably do not want to recall the tempo. Once exceptions to an "all inclusive" preset system are made, it's N*S*2.
I do agree that the way it is exposed could be more intuitive.
I'm willing to look deeper into this in the future, but my current efforts are on converging current developments into a release.
Fair enough - but there's something about the whole system that I don't understand. I have a synth with a number of parameters. Most of these parameters (around 20) I want to set differently in different presets and then be able to select a preset from my keyboard using MIDI Program Change. Selecting of presets from the keyboard works fine, but I'm having trouble creating the presets. Can someone please describe the procedure for creating (or editing) a preset?
Agreed. Which way round works best is a matter of the likely proportion of parameters you wouldn't want to be saved to those that you would.
I'd contend that in the majority of cases, you'd want most parameters saved (especially if you're used to preset systems on almost any other MIDI hardware), so it makes more sense to save everything by default, as opposed to saving nothing by default, especially with more complex patches.
a|x
I understand this, its what we expect, as we see it on other hardware and software synths - a 'total recall'
BUT the issue as Johannes pointed out, is this would use a lot of memory...
32bits for every parameters in your patch multiplied by the number of presets and then (and if memory serves me correctly), multiply this by the number of voices. its basically not really viable to do it like this... so it needs to be reworked.
of course, we must also remember in hardware and software synths, we don't keep this all in memory, so arguably this is the crux of the problem, the presets need to be stored on the SD card, and only loaded when needed.
(also Im not sure if presets are stored in sdram? perhaps non-active parameters storage should be in sdram, and copied to ram when 'loaded')
here of course, we need to be careful of the 'performance aspect', for 'instant switching'
the upshot is basically parameters need to be reviewed, and at that time preset management as well.
... its quite a big topic though, and an interesting area where I think feedback since release has highlighted many opportunities for improvements etc.
p.s. also, I would not want to 'chuck out the baby with the bath water'... the current system, actually is very different to a normal preset system, with some unique and very interesting properties. particular in a performance context - so I think we should have this too.
(perhaps by having both we might need two different/new names, to avoid confusion)
Id agree with that, I also had issues creating presets reliably... Im not sure its a counter-intutiive workflow, or there are bugs under certain conditions. I found it so frustrating, I gave up in the end 
After looking at it once again - and reading the documentation - I have come to the conclusion that my problem is that I expect that parameters chosen for a preset can be updated live. The documentation actually states that they can NOT be updated live. This creates a sort of 'catch 22' situation, as normally you would need to listen to your patch in order to decide what parameter value you want in the preset. This means that, at least to me, the current preset system is useless.
yeah, Ive just been doing a bit of testing, and frankly its broken in quite a few ways...
if it wasn't going to allow editing in LIVE then the EDIT buttons should be inactive
(in which case the edit/recall is unnecessary ... non-live would be EDIT, live would be recall)
but you get odd behaviour as it is current
e.g. store a preset (say 3) go live...
hit recall, gets the value , cool. (perhaps annoyingly it doesn't highlight stored values though) , and you can edit
now hit edit on the same preset (3) ... ok now its yellow
now if you change the value, it doesnt actually make any difference to the patch.... (unlike recall) and as you say is not stored BUT.... now go non-live... then go live again... now recall the preset, and magically it will use that changed value!!
basically the logic is a bit all over the place, which is why I think I gave up on it last time.
I think there are a couple of different use cases, for live mode
- I think in all preset modes, the preset values should be highlighted
- they would always be editable ( I you should always be change the patch)
- hit EDIT should store the value in the preset (only the presets available, should be active)
- recall should recall the stored values
OK, this leave one use case... which I think the UI is currently trying to do (badly)...
ideally, we want to be able to recall the preset as its stored in the patch!
... and thats an issue, as the number of presets is fixed, if we allow updating, then we dont have any where to keep this.
so there the problem... some users will say I want to be able to store the presets when its running. others will want to always be able to return to the stored 'patch' presets... and we can't do both without doubling the memory used.
personally... and Im sure others will disagree...
I think once you hit store... then that should be the new preset value...
of course before you hit store, you can still change values, and then hit recall if you want to go back.
what do you think @johannes, what was the current workflow suppose to be, with respect to 'EDIT' whilst live?
I think perhaps we can make some changes to at least make the UI 'make sense' and be consistent... but perhaps still with room for improvement for the future.
Preset info is actually updated live. The preset popup menu of a parameter is consistent I believe. The recall buttons are functional too. The parameter edit buttons in the toolbar have odd behavior, and I'm not sure how it should be expose this with a consistent behavior. I can't just switch my mind right now to diagnosing/testing this, need my focus on other deep stuff.
I can't just switch my mind right now to diagnosing/testing this, need my focus on other deep stuff.
I was more after, what is the intended behaviour?
given you say:
Preset info is actually updated live.
this sounds like, in LIVE we should have the following functionality....
RECALL
recall current preset
EDIT
first press, recall current preset - update display, mark params yellow (this all works ok 
)
then you should be able to alter the params , and the patch should change sound accordingly.
second press on same preset, stores that preset with current values.
(such that recall will bring it back, and it can be saved with patch when not live)
can I assume this is whats intended, so treat anything outside this as a bug , and I can take a look at?
I think this misses a use-case, which is common and very useful.
recall a preset, change settings , store preset in another preset.
this is useful as it allows variations to be built very quickly.
I think to do this, Id do one of three changes:
a) least 'change'
shift + EDIT preset # = dont recall just store
b) change in workflow, might confuse?
EDIT never recalls a preset, it simply stores (and we rename to STORE)
.. this makes it possible to 'accidentally' overwrite without thinking especially if your used to the old way.
but its much more 'consistent'.
c) we have a row of PRESET numbers, but no edit/recall row
press the preset, its a recall.
press SHIFT+preset its a store
(c) is the one Iike most ... Ive actually seen this elsewhere (e.g. max does this), it takes up less screen real estate, it wont confuse... as the look is different, so users will have to think - i don't think its easy to 'get wrong', as its pretty intuitive.
the only downside I see is you need to use a hand on a keyboard. (an option might be a 'long click' on a preset button for store ?!)
finally... it leaves us open to a keyboard shortcuts - number = recall preset, shift+number = store.
anyway, I know your busy... so can leave for now,
or if you just throw a few pointers to what its suppose to be doing, thats cool too.
Slightly tangential, but I've noticed it appears to be possible to assign MIDI CCs to parameters while Live.
I say 'appears', because they don't actually work when they're assigned this way, but there's no clue this is the case when you attempt it.
Seems to be another instance of the UI allowing you to do stuff while the patch is live that it shouldn't.
The worst case is of course that it allows you to completely corrupt a patch by editing object code while the patch is live. I've lost so many hours of work while working on custom objects because of this bug.
a|x
yeah, we do need to go through some of these things and either close them off (even if 'just for now') or implement...
I think generally, actually all of the popup menus are not relevant in LIVE.
(midi cc , mod sources, network disconnects, presets adding etc... ok, the preset values menu is kind of valid_
this is fixed in the dev version
Bringing fixes already developed into a release is exactly why I prefer to save this discussion for later.
Hey
I was wondering if it would be possible to add a scroll function for the preset assignment in Axoloti? Problem is when I want to use alot of presets, when I get to more than 22 I cannot se them on my Macbook screen. A scroll function could let us scroll further down for more presets.
Another feature that would be really great, for the all ready super great preset system, would be a drop down menu for the "easy assignable" presets. Right now there are 8 that is easy to set up, using top menu presets selector 1-8. What would be really great is having a drop down menu for all presets instead of just 1-8..... making all presets easy assignable. This wont change the existing system, just make it a bit more easy to use when you want to use more than 8 presets. (I think I all ready suggested this somewhere else, but I thought I'd add it to this post, which is also regarding the preset system):
moved to existing topic ...
also another reference to preset suggestions here.
I think the preset system is subject to review, on a number of accounts.
hopefully whilst we are looking at parameters of the next dev release, we can take a look at this too...
btw: point me to any other threads discussing preset 'suggestions' as id like them in one place, makes them easier to review at a later date.
Yes, might be a better name. I wil still in this post refrain to the it as presets.
Yes, exactly. As long as there are no clicks/blips/etc. when changing preset I am happy customer. And that I can use integer spinboxes as well is a must.
I am just thinking that drop down menu would make it easier to approach presets above 8. Not change the system itself, just the layout. It would make it more intuitiv as you mention. A long with the scroll for selecting presets.
An all inclusive system does also sound appealing, but it most be by the cost of something else, less DSP, memory etc. So I am still loving the system as it is now, set as you go.
Yes please dont change the preset system functionality, just the approach, maybe by doing what I mentioned above.
Anyway seems like a lot of other stuff on the table foe johannes and Tb, we will see if something better comes up down the road.