multiple preset with Bpatcher, Autopatter and Pattrstorage

Jesse Harlin's icon

I have what probably amounts to a simple question about the combination use of pattrstorage, preset and autopattr. I have apatch with bpatchers and autopattrs and a preset object that controls a pattrstorage. When I have one preset and pattrstorage in my master patch everything works wonderfully. I know that I am "hooking it up right". (greedy is set to 1)

Here is the question. i would really like multiple preset "waffles". I would like one that that loads with "my" presets, and is not necessarily editable. I would like another that is blank, and invite the user to save their own here. Finally, I would like a third with only about 10 steps whose function is to provide a complex degree of patch modulation via interpolation.

In other words, I want three preset object and three pattrstroage objects that will interact with the exact same autopattrs throughout my patch.

I have tried making unique pattrstorage objects, thinking they would be truly individual, and load their own xml files. The problem is that no matter how many I add, only one works. I am not hooking up multiple presets to the same pattrstorage because they may not have the same "number one", rather these will be more like three separate "banks" that have different conceptual meaning.

I figured this might have been tried before, but I am not setting the right flags. regardless, I am stumped. Maybe i need to partition a single preset into multiple parts?

Ben (super nice dude) suggested that "One option is to just forgo the preset altogether and come up with your own interface, using a matrix of buttons or something like that, that interact with pattrstorage."

I know that there are a lot of solutions to managing the presets, and this comes up often. I have read about a multitude of scenarios here and there, but none seem to match my problem. The forums are a great resource, and i read them often, but i think my "google-fu" is not strong enough on this, or perhaps i have a more unique problem than i realize. Maybe its a matter of setting a few flags? Seems like this should be simple to me.

I thank anyone who responds in advance for their insight. Even linking to a thread where this has been discussed, is useful. Even tangentially related information... such as ways to manage the pattrstorage without preset might yield fruitful information. what have you tried in the past that worked? I have read the documentation and the appropriate tutorials a few times already, and am not getting any 'inspirato' from them, and am surprisingly stumped by this unexpected issue. Again, thank you for any insight.

Edit: I have included a zip file that demonstrates the scenario. There are two patchers, a main and a sub that is instantiated a few times. You will find the first preset opbect oerates quite well whereas the others are "finicky"

Jesse Harlin's icon

I am reading around and seeing that more than one pattrstroage on the same patcher level causes problems. I suppose this means that my attempt at a multitude of preset objects working in tandem in this particular way might not work.

Therefore, what are some effective ways to partition singular prest object to interact with a pattrstorage? I will play with this myself and post any useful result.

nick.c's icon

hey there,

I think that you need to investigate the "bindto" and unbind messages for pattr objects. I think you can disable the connections between the the pattr objects and the controls you wish to recall data into.

for example, presets.xml may have the details for objects 1,2 and 3.
If you wish to only load the preset into object 1. set up your bang order correctly, so that objects 2 and 3 become unbinded before the preset number is recalled, so they do not receive any data.

hope this strategy is helpful.
PEACE!

Jesse Harlin's icon

I will look into this right away. I admit that I don't readily see where you are going with this, but more might be revealed after I examine the "bindto" material again.

...I thought that i was "binding" the presets to the pattrstorage, and they in turn were looking at the Autopatter (that in turn looked at my scripted objects).

I will post my results. Thank you for taking the time to respond.

Lokua's icon

Commenting to revive this thread to see if anyone has an easier work-around for this. Like the OP I'd like to have more than one preset system for different parts of a patch (global, param-group1, group2 etc). My patch has hundreds of UI elements btw - perhaps I should just forget about the idea?

felipe vaz's icon

Hi Lokua, I have a similar problem. Did you manage to find a solution?

Jesse Harlin's icon

Felipe, I did ultimately manage a solution, although my memory is fuzzy. I think if you check the timestamp you will see why. I posted this about 13 years ago, since then my life has moved on in fundamental ways and the intricacies of the 'preset waffle' have slowly faded away. I've learned more about programming since then. If I could go back in time, I'd tell my old-self that the preset waffle is a singleton (a word I did not know at the time) and shouldn't be used exactly like this. I was trying to use it as a micro-database interface for an XML file. I was doing it all wrong. If you have more than one, stop and think.

In the end, I made one big preset waffle if I recall. I then made an interface of checkboxes, that went 1:1 to the waffle. I divided these into the three groups: the "factory presets", ones I wanted to be selectable but not editable, the "user presets" and "the modulators". I used the checkboxes as a sort of proxy-pattern, and I was able to configure the checkbox 'waffles' to behave differently. I prevented certain behaviors here (like overriding the factory presets). It was sloppy work, to be honest.