Dynamic bpatcher loading/pattrstorage presets

Aug 3, 2008 at 10:58am

Dynamic bpatcher loading/pattrstorage presets

Hello list,

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).

Regards
WillyC

#39113
Aug 3, 2008 at 1:17pm

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.

#137270
Aug 3, 2008 at 5:46pm

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.

#137271
Aug 3, 2008 at 6:21pm

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.

#137272
Aug 4, 2008 at 11:05am

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
> done.

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
pattstorage…

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
main pattrstorage.

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…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#137273
Aug 5, 2008 at 7:43am

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
pattrstorage…”

I’m assuming you mean bpatcher here and not pattrstorage..

“…, you’d need to have a seperate pattr to store that in the
main pattrstorage.”

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.

Regards

#137274
Aug 5, 2008 at 8:57am

I was able to get your patch to work simply by giving each autopattr a unique name(i.e. for the dialsll patch and for the buttonsll patch).

Modded patch(kept in Max4.6) is attached.

#137275
Aug 5, 2008 at 10:38pm

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.

Strange.

A million thank you thank yous.

#137276
Aug 6, 2008 at 12:07am

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.

#137277
Aug 6, 2008 at 2:04pm

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
> pattrstorage.”
>
> 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…

raja schrieb:
> 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…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#137278
Aug 6, 2008 at 8:02pm

Hello again,

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.

Enjoy.

#137279
Apr 11, 2011 at 1:33pm

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.
Lee.

Attachments:
  1. knobs.maxpat
#137280
Apr 15, 2011 at 7:07am

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….

#137281
Apr 15, 2011 at 6:58pm

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.

#137282
May 20, 2013 at 6:03pm

Great thread, thanx!

#250014

You must be logged in to reply to this topic.