Preset of presets ?
No, I'm not talking about the overlord, mother of all presets. :-)
What I'm looking to do is the equivalent of Banks of Presets. How can I accomplish this ? I can't hook a preset object up to another (at least, it won't let ME do it.)
pattrstorage *is* the mother of all presets, and can easily recall banks of presets, interpolate between them etc.
Yes. Dive headfirst into the [pattrstorage] world ! (and helpfile ! and doc reference !) looks like a wall, but very much necessary/worth it.
I'm already using pattr\pattrstorage\preset combo to store presets, and yes, it's been working wonderfully well.
What I was looking for though was for the ability to select between BANKs of presets. It does not seem possible to connect a preset's output to another preset as you would hook up any other object's input to the left output of a preset object.
So, I'm recalling presets in one bank just fine already. I need some way to switch between these several banks.
Thanks Wetterberg and Vichug
You can use pattrstorage for banks of presets, that's our point, really - but you need to differentiate between "presets" and "the [preset] object" for that to make sense.
I'd do it by moving away from the preset object, to be honest, but that's probably my temperament, more than anything - oh, and I like morphing; the problem for you seems to be in [preset] being tied to pattrstorage.
How do you want your preset system to be nested? Just presets and banks of presets?
You *could* simply use a dropdown folder to select between the banks, instead of the preset object.
Yes, that's what I'm looking for; banks of 128 presets, and the ability to select between other banks, each with their own set of 128 presets. BTW, each preset has over 80 parameters.
By "dropdown folder," do you mean a dropfile object and a uMenu object ? I've certainly never imagined an architecture such as what you describe. If you could provide a technology demonstrator patch, I would appreciate the illustration for clarity. I imagine to access the presets within the pattrstorage json file, you would simply send messages to it.
Compelling concept, either way. Yes, I was kind of married to the preset object. It's interesting to learn that it's not really necessary. I'm ALWAYS looking for ways to use less objects and simpler code to produce the same results, so BIG thanks for that !
You can use either preset or pattrstorage. Each "bank" would just be a separate saved file (.maxpresets for preset object, or .json for pattrstorage). Then just select the file you want and read it into the preset or pattrstorage. You can use a umenu if you want to see the bank file names, or use another preset (a dummy one hooked up to just one number box, which you don't care about---so it doesn't store any other values), store all the slots so they're active, and use the number coming out to recall the file you want...again, by going through umenu, but hidden in this case if you want to only use the preset UI.
Pattrstorage is more powerful in a lot of ways, but preset is quicker to implement and works fine if you're only storing values on one patch level (it won't go to other levels, you'd have to use proxy values to bridge between the levels...a bit of a pain). The preset object UI itself is very useful too, even if it's not storing anything...a one-only-selected grid with lots of appearance controls. That said, you can also use [tab] for similar purposes.
this is what you'd end up with - ish:
So you use two preset objects to read and write to a 3rd and large enough preset object to accomodate all slots in the former two; a + b = c. That's pretty cool. Simple, yet elegant ! :-)
As I didn't see this when I already committed to and quite far along with another solution, I hope I won't need to turn back to your elegant solution. I'm very happy with the direction I've taken it and I think it will work like a charm, but I have an issue I need to resolve to make it perfect :
I went the UMenu\Preset object combination to create .maxpreset files which some bpatcher abstractions will use as read only through their own umenu objects. They'll pull the information within them, and use them as static presets to choose from.
So, I've done all, including the data entry to create the .maxpreset files, but now cannot pull the info from them ! Bummer. I'm sure there's a way, and perhaps with JS, if not an architecture with some standard Max objects.
Any ideas there ?
@Wetterberg : You know, I didn't say thank you. I apologize.
I really do appreciate your consideration.
Thanks,
Glennzone
@SeeJayJames : Could you elaborate further on the solution you described, particularly as regards the read only access requirement I cited above (just after Wetterberg's last post). I want to be able to access the .maxpat files in an abstraction, but they don't show.
Something like this. You need to create the .maxpresets files, then you can load them into [umenu] and access them using a dummy [preset] just for the UI. Or you could use [tab] to select...or the [umenu] itself...up to you:
Having a little difficulty understanding this. So these dummies are the ones that go into the abstractions ?
It seems the way you illustrated it, this would allow only one maxpreset file loaded at any one time, and then the dummies can access that one maxpreset. That won't work in this setting.
The real preset has a numbox and a textedit object hanging off the left outlet. That preset is what created the 11 maxpreset files I'm using. It doesn't seem I can use another instance of umenu\"prepend read"\preset to load the desired maxpreset file in the abstraction.
My task is that now these maxpreset files are created, there may be multiple abstractions accessing any one maxpreset file. I want all abstractions (containing the umenu\"prepend read"\preset\numbox\textedit object combination) to access any maxpreset file you want (Read Only). Your patch above doesn't seem to do that.
I'm sorry I don't understand well enough what you've got going. What you're calling the "real preset" (being accessed by each of these abstractions containing their own umenus) is actually a .maxpreset file itself.
My last attempt was to create a umenu\"prepend read"\preset object configuration, with my numbox and textedit objects hanging off the left outlet. Selecting one of the maxpreset files in the umenu, did not allow me to populate the numbox or textedit objects hanging off of that preset object.
I don't know what I'm doing wrong. Maybe the scripting names ? The names of the numbox and textedit objects have the same scripting name in the preset object which created the files, as they do in the copies\dummies of the preset object which created the files in the first place.
Any abstraction instance can access any maxpreset file you want, at any time. The preset itself is not a maxpreset file, it just reads them. So your 11 maxpreset files could be read into the preset object within any of the abstractions, including the same file in different ones at the same time...they don't communicate with each other. Should be no problem.
Scripting names aren't relevant here, so no worries about that. However, don't duplicate or copy-paste presets with their attached objects. They don't copy that way. Just use the one in your abstraction, which could have any of the 11 maxpresets "banks" loaded in at any time.
To simplify, get rid of the dummy preset objects, and just use the real ones (that you've created the 11 files with). Then just use the [umenu] to load the files/banks. Make sense? Once you have that working, you can use whatever UI you wish to access the [umenu], including a dummy [preset]. Maybe that was causing the confusion, which I can understand!
I have things communicating, and the preset objects within the abstraction are loading successfully, but the numbox and textedit objects attached to the preset are not pulling the data from the preset object.
I took a look at the .maxpreset file and found there are specific references within the data record which point to "obj-96" and "obj-86". I believe that to be the problem. Here's an example of the test record I created :
{
"preset_data" : [ {
"number" : 1,
"data" : [ 8, "obj-96", "textedit", "set", "This", "is", "a", "test", 5, "obj-87", "number", "int", 16 ]
}
, {
"number" : 2,
"data" : [ 5, "obj-96", "textedit", "set", "initialized", 5, "obj-87", "number", "int", 0 ]
}
]
}
I believe I can probably find out what the obj-nn id's are for the number and textedit objects within the abstraction, and then do a find\replace all on the .maxpreset files. Is this what I have to do, or am I missing the forest for the trees ?
Something's wrong, you shouldn't have to do a find/replace. The "obj-96" etc. are just the preset identifying the particular objects that it's storing, I believe they are numbered sequentially in the order created (and you can see them if you look at your overall patch as text).
Are the values listed the correct ones that you stored in the preset slots?
Are the "obj-nn" values the same for your various .maxpreset files?
I got it working, but had to re-invent the wheel to do so. I didn't do a find\replace, but I encapsulated, and then made an abstraction out of the preset, textedit, and number objects. Once I did that things worked like a charm.
Boy, it's nice to finally be getting fluent with this stuff ! :-)
I'm still looking for good answers on the JS questions I've posted here :
and here, where I make my offer to put something comprehensive and decipherable in the way of JS in Max :
Hi guys! Picking this post in 2018 :)
I'm trying something similar on a particular device In Ableton. So what I need is to be able to change to any bank without having to load any file, this way I can change between programs and banks inside any playing clip. Taking this further is it possible to use the same logic but applied to every device on a track? Something like a maxforlive device that can snapshot all devices in the track so that after it can recall by it's respective program and bank? Can anyone help me here please? I'm kind of noob in m4l... Thanks :)