Pattrstorage with umenu for naming presets?
Hi All,
I am pulling my hair out here, I am trying to make a system where i set all my UI objects (M4L and Non M4L Via Pattr) and then i click a save button, a dialog pops up and then i type in the name of the preset which loads into a umenu. I do this a couple of times and then i have a umenu in which i can click on the names and recall presets.
I have manage to get this far but when i save the live set and then recall it the umenu is gone. I can only get the settings back if i press save again and save another preset then they all apear although they are jumbled up and the last preset i saved in the live set befor is missing.
Has anybody out there made a simple save/delete preset system which uses a menu of some kind and also saves that info with the live set.
Many Thanks
Have you enable parameter mode for the umenu in the inspector?
I have done that on umenu, pattrs, pattrstorage does anbosy have an example of a patch where a pattr storgage uses a umenu to save presets and then recall them with the live set?
Thanks
I tried to build something like this a couple of years ago, and (almost mostly) got it working. I'll get back on it someday (not now, sorry.) But I'm a little baffled someone hasn't built a nice front-end to the pattrstorage system. Methods for preset storage, organization and recall are so standardized in hardware and software alike, it seems to me like a pattrstorage control object could be justified as part of the basic max object set.
Struggling with this right now also. It seems that umenu content cannot be saved in a pattrstorage.
There are a couple of inelegant workarounds, but I haven't been able to find a concise solution.
The general consensus is that you also need to dump the menu into a coll object, meaning you will have two additional files (one for the pattr and one for the coll) to deal with.
Curious to see if there is a better way.
You can do it with coll and dict, bloody mission but it works
i've got something that I use, which only uses 1 pattrstorage file, to populate a umenu which you can edit etc-- I'll try and "genericise" it and post it within the next 24 hrs, if you're interested...
OK here it is, hope it's of use.
I had come up with a solution but this is the best i have seen by far. Nice one Floating Point!
You have defiantly help a lot of developers over come a massive problem!
Thanks for the feedback! I wasn't sure how useful this might be for others-- If you aren't sure about something or spot a problem let me know.
T
Hey,
that's a very simple form of a patcher with which you could 'store' umenu items.
Don't know if it helps.
I post it anyway.
Cheers
Peer
nope doesn't work correctly....sorry
Mattyo, how do i install all this?
This works perfectly for me to save presets in a uMenu and to erase them if needed.....without any 'save changes' messages when closing the patcher.
Hope it helps
Cheers
Hey,
here is an improved patcher for giving titles to presets into an uMenu, saving theme, recall them and erase them if not needed anymore --- and all that without any 'save changes?' messages when closing the patcher.
I hope I took all things which could go wrong when entering a title into consideration.
If you are using the patcher and find any bugs or things I forgot, please tell me....I would appreciate it very much.
Have fun.
Cheers
Peer
I have a bpatcher that works well for me. You can select a slot number, give it a name, and choose an interpolation time.
main patcher
bpatcher:
`
Florent, im struggling to get this working, do i have to save the two files somewhere?
hey, yes you should save the bpatcher somewhere on your Max search path, and then open the other patch
Hi Florent,
I want to test your storageinterface. But in your "saver" - Bpatcher, there is a "passage" - object integrated which I miss - doesn't seem to be a Max - standard - library item. So, where can I get it from to run your preset - storage - UI?
Thanks for advice!
Yeah, i spotted that one too,
oops sorry
passage is just something stupid like this:
here is a version of the bpatcher without the passage object:
there are two arguments for the bpacther: 1/ its name, 2/ default interpolation time
be sure that the receive object that's connected to the pattrstorage has the same name as the bpactcher, so it's like [r name_pattr]
give a name to the pattrstorage, and the first time you quit, it's gonna ask where you want to save the name.json
send an int to the right inlet if you want to remotely control the bpatcher
to save a preset: 1/ select its slot number, 2/ enter a name without space, 3/ click somewhere outside of the textedit object, 4/ click save, 5/ save your patch
to replace a preset: 1/ select a preset, 2/ click replace, 3/ save your patch
let me know how it goes!
Hey all, I've been using Floating Point's solution for this and it's working great mostly, so thanks! One thing that was bothering me though was the recall not working properly when selecting old states from the umenu. It turns out he/she was missing an unpack for the recall dump buried in the menuFill subpatcher (next to the "not sure what this is for" comment hehe). Works like a charm now!
I've been using the version that Dusty uploaded, and wow: this is awesome. My Max skills are nowhere near the level to come up with something like this. So thank you to Floating Point!
I'm having a couple nagging troubles, though. One trouble is that selecting a different preset only changes those parameters that were edited before I saved a new preset.
So if I:
1) start with preset 0 (init)
2) change parameters A and B
3) save that preset as preset 1
4) return to init and change parameters A and B to totally different values than their values for preset 1, and also set new values for parameters C and D
5) save that preset as preset 2
6) then load preset 1...
...the values for A and B will change, because those were changed before I saved preset 1. But the values for parameters C and D will still show the values from preset 2 rather than showing the init values from preset 0.
So how can I fix this patch so that it saves the state of ALL parameters--even ones I haven't touched--when I save a new preset?
I was just making sure to manually wiggle all parameters before a preset save, but now that I'm at 128 parameters in my patch, that is getting to be unfeasible for every preset save
Thanks in advance! I can post the code if that helps...
Absolute god-send. The time it would have taken me to figure this out... Thank you Floating Point.
As I'm learning, and still don't understand a lot of what is going on here, I've tried spacing the whole thing out, encapsulating the odd section, and commenting A LOT. I hope this is useful for anyone with a similar skill level to me. Having said that, this patch caught me A LOT. Sometimes trying to learn what messages I can and can't send to complex objects like [pattrstorage] can be really tough, but the heavy use of [route] in this patch has definitely given me a deeper understanding of Max, and not just these objects.
Regarding Dusty's comment - yes I noticed the recall problems, and thought the 'don't know what this does' note funny - but can't see any new unpack objects, and the old 'don't know' comment is still there? Perhaps I misunderstood your comment.
I've also had the occasional problem selecting a preset from the menu, which monitored from the max window at various points shows some changes have been passed on, but the menu remains the same. Not sure how to approach that one.
I also noticed there's a 500ms [metro] just monitoring whether the preset has been modified. Is this the best way of tacking this problem?
I also noticed the old 'Write File' button is, is more of a Save function, but it seemed you only got to select where to save files when closing the program; that's what the [freebang] is for in [p writer] right?
So I added a 'Save As...' button and changed the original 'Write file" to 'Save'. Hope people find that intuitive and useful.
I've also added a few questions (highlighted in red) in the patch which I hope people might (in time) answer and correct, this sort of thing is not only useful practically, but can be one of the best ways to learn.
Thanks so much again!
I'm so glad this patch has been useful-- It's been so long since I made this (or used it actually) that I can't remember precisely why some design decisions were made. But given the interest and hard work gone into this "mini-project" especially by exeterdown, I'll go through it and try to address any queries you might have.
I think the reason I chose "write" as a command instead of "save" is because if I remember correctly the pattr system has a save command which does not write to file unless attributes are set up in a specific way, so "save" can be misleading (ie it saves to a slot in pattr-memory but does not write to file).
And the strange behaviour you describe where it saves only when you close the program was because it was originally designed as a standalone for a client, and this seemed to be a foolproof way to save if the user forgot to manually save after finishing an editing session... (it was a component in a very extensive/elaborate lighting system for an installation) ...anyway I'll go through it over the next few days when I get a chance and perhaps try to make it more generic/streamlined, and also attempt to answer your questions.
Wow, super quick reply for a three year-old thread :)
Yep, cool, that all makes sense.
I'm just trying to tie the version I posted back into some of my other patches now.
Also, with [pattrstorage @savemode 3] the pattrstorage will automatically prompt to save a file when freed - perhaps this changes the need for the [freebang]?
Thanks Exeterdown your patch is awesome! This forum post is kind of like pattr development, pretty badly needed! But I am confused as to why you think autopattr wouldn't be good with your patch? Do you have an example of of your patch using autopattr?
Cheers! - Thank Floating Point!
I don't have an example using autopattr because I don't use autopattr.
I took some advice aages ago from some more experienced Max heads, which was to manage things like this manually. It will help you learn your patch more directly, and have better control over things like nested pattr systems. Essentially it's just old-fashioned good programming practice, which I appreciate.
A bit like using trigger instead of just dragging multiple patch cables from a single output; it might not matter, but it's just good practice.
Right on that makes total sense, thx for passing those ideas along!
wow - y'all did some incredible work with these. Thanks so much to Floating Point and the people that posted mods on their original patch. these were so helpful to my project and just generally informative.