MuShoo

Hi all - going to try and describe this issue, and maybe make a demonstration patch. Pattr always confuses me so hopefully I make some sense.

I have a number of identical bpatchers in my patch, and the first argument for each is an ID number (1-6), which I use to name some UI objects (so things like #1filtergraph). I need each UI object named slightly different because I'm using thispatcher scripting to bring certain objects to the foreground or send them to the background, depending on what needs to be at the front at the time, and having them named "filtergraph[1]" wouldn't work as nicely.

Problem is, I want to have some presets for these bpatchers, such that the bank of presets can be accessed by any of them. But when I put them into pattrstorage (contained in the bpatcher), they save variables based on the instance name -- IE, saving a preset in instance 2 ("2filtergraph") makes it unusable in instance 1 ("1filtergraph"). I've tried using aliases -- so everything is also labelled without the numbers -- but that doesn't seem to work.

Any ideas? I'm hoping to also have a top-level pattrstorage so as to recall full sets of all 6 bpatchers.

I have a number of identical bpatchers in my patch, and the first argument for each is an ID number (1-6),  which I use to name some UI objects (so things like #1filtergraph). I need each UI object named slightly different because I'm using thispatcher scripting to bring certain objects to the foreground or send them to the background, depending on what needs to be at the front at the time, and having them named "filtergraph[1]" wouldn't work as nicely.

Any ideas? I'm hoping to also have a top-level pattrstorage so as to recall full sets of all 6 bpatchers.  

Hi all - going to try and describe this issue, and maybe make a demonstration patch. Pattr always confuses me so hopefully I make some sense

complex-pattr-problem

pattrProblems.zip

How about doing ui front\back management inside bpatcher abstraction? Then you won't have to address objects directly from outside, and they can have the same scripting name.

How about doing ui front\back management inside bpatcher abstraction? Then you won't have to address objects directly from outside, and they can have the same  scripting name.

Y'know, I'd actually already been doing that inside the bpatcher. I guess I just assumed that I'd need to give objects unique names throughout the entire patch (and thus also subpatches), but I just tested it and I guess I don't! Soooooo this should work nicely, then! Thanks!

Though I'll have to see what happens when I try and save a preset for the entire overarching patch, too -- not sure what problems that'll cause, having nested pattrstorage objects like that.

Y'know, I'd actually already been doing that inside the bpatcher. I guess I just assumed that I'd need to give objects unique names throughout the entire patch (and thus also subpatches), but I just tested it and I guess I don't! Soooooo this should work nicely, then!  Thanks!

Complex pattr problem