Presets for poly~ subpatches?
I've got a [poly~ mysynth~ 12] object which creates up to twelve different instances of a subpatch [mysynth~] as and when they are needed.
However, when I load up the main project, all the settings inside the [mysynth~] patch default to 0 as would be expected. How can I make it so that upon loading the patch, all 12 instances of the subpatch settings are loaded in from a preset?
Alternatively, would you suggest that I make all the patch settings (no. of oscillators, lfo rate e.t.c) accessible from outside the patch and just set up a preset in the main project?
Cheers
I am not the best person to take advice from, but here is my advice none the less.
The presets object is unreliable for this type of thing. I have noticed that if you cut and paste a preset object it will loose it's settings. What you can do is set up some message boxes for the numbers you need on load and hook it up to a loadbang object. Also look into the objects coll, pack, and unpack, they are very helpfull and more reliable than the preset object.
Still young with Max, but hope this helps,
Andrew Burke
Using a poly~ is like using a bpatcher or an abstraction: you can save a set of master presets within the main file, but any changes you make to the presets of an iteration of that file will be lost once you close. So if you do use presets (with the preset object) in the poly~, make a set of (however many) "factory" or default settings. Then each of the iterations can access those anytime. You can send an index number into each poly to access one of the presets. Loadbang preset 1 (or whichever, maybe a different one for each) and you're ready to start.
Better yet, use the colls as mentioned here. Continually store all your information from each poly~ into a list, with just a bang at the leftmost inlet (it waits until it's told to bang, or maybe it does it automatically like an Undo). When you want to store a state, have a way to bang the list into a coll with a unique index. BUT--bang the list *out of the poly* and back "up" into the parent patch where the coll actually is (prepend/index the list with the poly~'s number if you want to store it as "from that poly", otherwise it'll be a "general" coll). That way the info will stay upon closing. Then, with some routing, any list that was saved into any coll could be used by any poly~, to refresh its values.
Beyond this, of course, pattr will store and manage lists too... so why not bang that same values list into a series of pattrs instead of colls? Then you'd get interpolation options too. Like the colls, be sure the pattr is on the main patcher level---that's the only "real" patch, the others are instances of another patch and cannot (I believe??) save their own presets, colls, or pattrs (unless you write to a file, which means they're not saving their own data anyways). In other words, the presets/colls/pattrs that are saved in the main abstraction file (that you make the poly~ or iterations *from*) will remain unchanged regardless of whether you store new presets/etc. in an iteration. However, you can change these presets/etc. by opening and changing the actual file.
It was a bit strange to discover this in my own experimentation, but it seems true. If I'm horribly wrong I'd like to know... it's a little much to wrap one's brain around, but it seems like there's a lot of flexibility that's provided with this design.
Once you have a bunch of presets/etc. it's all about deciding how much functionality you have available at the topmost level vs. within the polys~.
-C