Dynamic bpatcher loading/pattrstorage presets
Glad to have joined up having found this an invaluable resource for the last year or so.
Alas the time comes to pose a query as it seems searching will not turn up a solution for my problem…
I am using pattrstorage/autopattr to recall presets that consist of item numbers directed at collection of ubumenu objects. These in turn use scripting to ‘replace’ the contents of a collection of bpatchers.
I would like my preset to not only restore the configuration of the ubumenus, but also of gui objects within the bpatcher subpatches. This of course can be done by including autopattr objects within the subpatches.
However, I run into trouble as the parent pattrstorage xml file cannot ‘know’ in advance what gui objects will be present in each subpatch after it is loaded (as exactly which subpatch gets loaded is not predetermined).
Is the best way to workaround this therefore to have secondary pattrstorage objects within the subpatches, whose individual presets are then loaded via the parent pattrstorage? If so how would this be done.
Failing that can anyone suggest an alternative method?
Sorry if this is repeating old ground; if so could someone point me to a relevant thread (as yet I have not unearthed a suitable solution in the archives).
To clarify, attached is a zip folder containing the necessary parent and subpatches to demonstrate the problem.
The patch named ‘parent’ is the one you’ll be needing, and the two subpatches will need to be within Max’s searchpath for the preset/ubumenu recall to work.
I’m using max 4.6.3 on Os X 10.4.11.
I think if you use autopattr, you would probably need an additional set of pattrstorage object embedded within the bpatcher-called modules, then have an inlet so that the outer pattrstorage preset number would also be sent into the module to recall the embedded pattrstorage objects’ presets at the same time. Sorry to write that so convoluted-like but you probably understand. I haven’t really tried looking into pattrhub pattr, etc. to see if there’s other ways, nor looked into the "greedy" flag of pattrstorage storage object, itself. You might want to check those out, too.
one more thing, if you’re using the "replace" message in scripting to replace what’s inside a bpatcher, you would also need to set it up to load in xml files right away upon each replacement because, i may be wrong, but "replace" will probably be destroying the replaced subpatch as well as the memory allocated for it. You might be better off, creating two bpatchers, naming them both, and then sending "hide" to one and "show" to the other(via thispatcher scripting) or else, putting both the subpatches into one bpatcher and simply changing the bpatcher’s display offset.
Willy C schrieb:
> Is the best way to workaround this therefore to have secondary
> pattrstorage objects within the subpatches, whose individual presets
> are then loaded via the parent pattrstorage? If so how would this be
Yes, that’s the way to go. The pattrstorage in the subpacther will only
expose itself (dependent on the greedy settings) and hide the other
pattrified objects. If the pattrstorage has the same name for your
different subpatchers, only the preset number will show up in the main
But you want to store also info about which patch you loaded into the
pattrstorage, you’d need to have a seperate pattr to store that in the
I guess you know that a scripted loading of bpatchers containing DSP
objects will interrupt audio and might create dropouts/clicks in bigger
patches (which can be avoided by the use of poly~ objects in Max 5…)
Firstly thank you for your responses thus far.
The consensus seems to be using nested pattrstorage objects then, whose presets are recalled from the top level patch.
However, one point of Stefan’s confuses me:
"But you want to store also info about which patch you loaded into the
I’m assuming you mean bpatcher here and not pattrstorage..
"…, you’d need to have a seperate pattr to store that in the
Do you mean my top level patch should have pattr objects bound to each of the pattrstorage objects in the subpatches? My understanding is the top level pattrstorage sees those below it anyway. Presumably then these pattr objects would act as a mechanism for communicating with the lower level pattrstorii?
I’m keen to keep all the preset information (for the parent and subpatches) contained within a single xml file, alas this scheme clearly won’t support that.
As an alternative I am going to try using ‘other’ objects (perhaps a coll) to recall the state of my ubumenu’s, thus loading the ‘structure’ of the patch (by loading bpatchers containing the required DSP subpatch – clickless loading to come, thanks Stefan), followed by loading an xml file with a single preset into the parent pattrstorage. This will restore the subpatch states via nested autopattr objects.
However, I can’t get this to work either, as once the xml file is ‘read’ into the pattrstorage I cannot recall presets – see attached example. Perhaps a misunderstanding on my part of how to use pattrstorage?
Any help much appreciated.
I was able to get your patch to work simply by giving each autopattr a unique name(i.e.
Modded patch(kept in Max4.6) is attached.
Many thanks Rabid.
This is working for me now too. I don’t suppose you can elaborate on why this works though? The documentation doesn’t seem to suggest naming autopattr objects is necessary. I am also puzzled by the fact that changing the autopattrs name doesn’t alter the behaviour.
A million thank you thank yous.
I’m not sure why this is. If I were to guess, the reference docs talks about how if you don’t name it, a semi-random name will be generated like, "u197000004", so i think everytime you do a "replace" in your script, it might be generating a whole new name and then the pattrstorage object is unable to see it as a result of all the new names constantly being generated with each switch. But… that’s just my guess.
Glad I could help.
Willy C schrieb:
> However, one point of Stefan’s confuses me:
> "But you want to store also info about which patch you loaded into
> the pattrstorage…"
> I’m assuming you mean bpatcher here and not pattrstorage..
Yes, of course…
> "…, you’d need to have a seperate pattr to store that in the main
> Do you mean my top level patch should have pattr objects bound to
> each of the pattrstorage objects in the subpatches?
No, your main patcher/pattrstorage needs to know which patch you loaded
into the bpatcher, or it would try to recall a preset, which doesn’t
find its objects, because the time you saved it, a different patcher
might have been loaded… You also need to make sure the correct patcher
is loaded before you recall its preset. Don’t know if priority would be
enough, as the patcher needs time be loaded.
I would consider a system which would have several pattrstorages and
multiple xml files more robust. You can place all xml’s into a folder to
keep it clean…
> I’m not sure why this is. If I were to guess, the reference docs
> talks about how if you don’t name it, a semi-random name will be
> generated like, "u197000004", so i think everytime you do a "replace"
> in your script, it might be generating a whole new name and then the
> pattrstorage object is unable to see it as a result of all the new
> names constantly being generated with each switch. But… that’s just
> my guess.
I guess its a proof… If you look at the stored xml file, all values
are referenced by their object names. If the names change, it can’t work…
Alas I couldn’t satisfactorily implement Stefan’s proposed multiple pattrstorage solution, although I have come round to multile xml files.
Attached is my now working solution for completeness (and anyone else interested), showing the system working with two bpatcher subpatches (thus it is scalable to control any number of bpatchers)
It uses one xml file per patch preset (or as I’ve now named them song – the idea being my performance patch can now be enhanced to have a per song setup recalled at the touch of a button).
As per Rabid’s input, named autopattrs are used in the subpatches. Interestingly they do not need to be uniquely named – it seems having a unique scripting path (each bpatcher has a unique name) allows reuse of the same patch (and hence autopattr name) within multiple bpatchers.
Required enhances at this stage would be:
– Better specification of where the xml files are stored (by default it is saving them in my MaxMSP 4.6 folder)
– Automatic re-writing of the coll so it’s contents reflect changes made by the user to the ubumenus.
– Multiple presets per subpatch
For now though I’ve got the basic mechanism working with the lists help so many thanks. The above points I can all handle myself but incude as suggestions for anyone else who adopts my patch for their needs.
Hi all, I am having the exact same problem and I have tried to follow this feed but still cannot get it to work. I have only been using max for about six months and have no programming history at all. I have placed in a parent patch and two subpatchers to show my problem. If at all possible could someone correct my patch as due to me being a noob I struggle to understand the language of max talk (if I may call it that) thanks in advance.
Here is a more recent attempt I have implemented to solve this problem, having seen this thread resurface.
As per Stefan’s original advice, it relies solely on the pattr system (as all good Max patches should…)
The only ‘flaw’ I can spot offhand is the preset in the child patcher (loaded into the bpatcher) is recalled after some arbitrary length of time (500ms in this case). It would be safer to have the child patcher send a bang out an outlet, then use this to recall the preset (i.e. once you are sure the child patcher has loaded).
Again, as mentioned previously, you should only use dynamic bpatchers to load UI type patches. Couple this with a poly~ to load to corresponding dsp sections.
Zip contains three patches (parent, dials and sliders) and their corresponding json files (for the pattrstorage objects) to demonstrate dynamic switching in action.
Of course, the whole job could be made much easier if one could bind a pattr object to the @name attribute of a bpatcher….
Corrected a bug in my previous post. The ‘parent patcher’ now correctly stores the selected preset in the the child patcher.
I also implemented a little logic to make the ‘child patcher preset recall’ only occur once the read has completed in the child pattrstorage.
Seems to be working seamlessly now (though I have not attempted to ‘manage’ the dialogue popups required to save the various pattrstorage writes that occur when you close the patcher). Hopefully others can adapt this to their needs.
Great thread, thanx!
Hi, I’ve messed around with the same problem for a number of years, I’ve just finished working on a modular system using dynamic [poly~] and found a relatively simple way of handling the save problems. the solution is to have the top page contain all off the dynamic [poly~] load GUIs and a [preset] not connected to a [pattrstorage] on this preset you save all your tracks or session [poly~] information. now in a [patcher] you place a [preset] attached to a [pattrstorage] and all of the [poly~] objects for the to level load GUIs. Your work flow using the system is to save the lower level preset as presets to a track, then the top level preset as a number of tracks. Id also name the song preset saves so they contain the preset number of the top level preset its for. obviously this system only allows you to dynamically change [poly~] in-between tracks/sessions (as the relevant lower level presets will need to be loaded).
Forums > MaxMSP