Forums > MaxMSP

Seeking a reliable system to manage pattrstorage presets for dynamic bpatchers

Jan 28 2012 | 9:02 pm


I can't find a reliable way to associate pattrstorage to bpatcher objects with dynamically loaded patchers. You can see the structure of the project below.

The idea is to have several slots for sound transformation. One can choose which fx is used in each slot. When a specific fx is selected using an umenu, the fx is loaded in a poly~ object and its GUI is loaded in a bpatcher. There are 5 slots but only one GUI can be seen at any moment. The user can choose which slot to see (buttons with yellow outline in the structure) and the offset in the global GUI container bpatcher is set to move the view over the corresponding sub-bpatcher containing that slot's GUI.

Each fx GUI's patch contains a local pattrstorage object for presets specific to this fx.

I want a global pattrstorage to remember which fx is loaded in each slot and the number of the most recently created/loaded preset. Any time a local preset is created or loaded its number is transmitted outside the fx GUI to the global GUI bpatcher where the number object containing it is associated with the global pattrstorage object. Presets for the global pattrstorage might be created when both an fx is selected and a preset is loaded/created in each slot.

When a preset is loaded in the global pattrstorage object the fx selection is set trough the five umenus (red outline). Each umenu then loads the right patchers in its correspoding poly~ and fx GUI sub-bpatcher (green and blue outlines). The preset number corresponding to each fx sub-bpatcher is loaded by the global pattrstorage.

However putting the preset number in the global GUI bpatcher doesn't work so easily. A 500 ms delay (pipe object) is mandatory before sending the number to the fx GUI sub-bpatcher. Also, another delay is mandatory inside the patcher loaded by the sub-bpatcher. This solution would be acceptable if it were completely reliable (althought it introduces a 1 sec. larency) but it is not. During one session it worked but the next day the preset numbers were not transmitted to local pattrstorage objects and I haven't any clue about the cause of this change.

Is there a reliable alternative ? Even better: a solution eliminating the need for delays ?

Please note the patcher runs under Max 5.1.9 on a Core 2 Duo MacBook Pro.

Thank you in advance for helping.


  1. ispattrstorageuptothetask.png


Jan 28 2012 | 9:05 pm

For those who had not guessed it: the GUI for each slot transmits the state of all its parameters as a list to the corresponding poly~ trough a send/receive connection.

Jan 29 2012 | 3:53 pm

I had a long fight against Max in this point. The weakness here is that asynchronous operations like loading a patcher file from disk do not report when they are finished. My workaround: every patcher which will be loaded at runtime contains a "loadbang" attached to "deferlow" and maybe a "delay" to send a bang to the patch which originated the "load" request. Inside there you find a construction like this:

r bPatcherIsNowInMemory
t b stop
| |
del 5000
continue processing

Every loaded patcher in the chain stops the delay and triggers it again, until all "late comers" have finished. Then continue with loading the pattrstorage data which will find in return all receiving pattrs now in place.
Secondly I put a "pattr" for every parameter used in a audio processing patch direct in there. Consider these as the "masters". The user interface bpatchers are "slaved" to them using "pattr foo @bindto master".
During loading of the bpatchers I use "pattrexists" in a loop to make sure that the "pattr"s exist before trying to bind to them. On a successful @bindto all parameter values are forwarded to the UI and all parts fall into place.
You can download the whole system here: -> sources for tLb
An overview of the parts is here:
The concrete patcher example is in /tLb/lib/Sessions/tLb.OpenSessionController.maxpat

Attention: the whole thing is not yet Max 6 savy.



Jan 29 2012 | 11:57 pm

Thanks a lot Thomas !

Jan 30 2012 | 1:00 pm

Finally I found a simple solution: each dynamic bpatcher sends a bang to a specific outlet upon patcher loading and this bang triggers an int object where the preset number has been recalled by pattrstorage. I could even remove my pipe objects. Elle est pas belle la vie ?

Jan 31 2012 | 2:34 pm

Hi Roald,
any chance you could post a simple example? I’m struggling with something similar at the moment…

Jan 31 2012 | 3:20 pm

Here you are. Please note it’s a simplified version. Among other things only the default and fragmentation fx GUI+circuit are provided.

Local presets must be created and chosen before creation of a global preset. I am using Pelado’s for global presets but it is not mandatory.

I have tried to use a preset object to save and read local pattr’s presets. Actually the object reflects when a new preset is created with a "cabled" message to pattrstorage but I can’t manage to make the .json file updated when the shift+click on preset’s slot method is used. Grmbl.

Jan 31 2012 | 3:50 pm

With this updated version of the fx’s GUI I can combine the use of autowatch to update all instances of the same fx’s GUI upon preset storage with storage trough shift+click on the preset object.

Jul 26 2016 | 2:14 am

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

Viewing 9 posts - 1 through 9 (of 9 total)

Forums > MaxMSP