hi, thanks for any help in advance..
I have a sequencer that Ive started where I have sixteen "cells" that store the value of a corresponding toggle to one of four message boxes, to recall different patterns and they use the pattr object to relay whatever state is being called out of the cell back to its toggle for visual feedback without a getting a stack overflow…
it works, but it takes up alot of space. I’d like to be able to put the cells into a subpatch with 16 inlets to route the toggles to, but this messes up the pattr objects ability to bind to the toggles.
So… in the pattr help file it says that the problem can be solved with a message that uses :: to specify the location of the object to be binded, and it gives an example with a subpatch called "down" and the message: "bindto down::clunky" so if my toggles are in the main window and the pattr objects are in a patcher inside that window, I thought the message should be "bindto seq::a" since the name of the actual max file for the sequencer is seq, I thought that would correspond to the main window. but it wont work.
so, its kind of an annoying problem to even explain let alone try and solve, so much thanks for anyone willing to lend a hand. also if this can be done with a creation argument to the pattr objects that would be even better. I attached the file, also Im new to max, so if Im going about all of this the wrong way let me know. thanks alot!
i didn’t really take a look at your patch but it sounds like you want to use a ‘parent::a’ binding, which will go up in the patcher hierarchy. something like [pattr seq parent::a].
I have a few different step sequencer examples on my examples page: http://www.xfade.com/max/examples
Here’s a somewhat simplified version of your patch. I’m not sure I would use checkboxes like you have but it works.
nice! thanks alot
Chris, that is a much much simpler solution. I guess I’ll have to learn about the autopattr and pattrstorage objects to figure it out. its alot simpler though, makes the cells concept I had going seem a little ridiculous, but thats actually what I was hoping to find out. the renaming alone of all that stuff alone (on my patch) to make extra channels would be impossible. thanks again.
There may be a specific reason why you would want to do it the way you’re doing it, but I’ve attached a much easier/quicker way to achieve a sequencer like this. I’ve used autopattr and pattrstorage to store the state of one single object: matrixctrl which is attached to a router object and these two objects working together with pattrstorage and autopattr achieve the same thing as the system you’ve created. You can also use your own picture file within matrixctrl to customize your UI so your not chained to the look of toggles,etc. There is an xml file which needs to be read in to pattrstorage, too, to recall the presets, but the patch, if kept within the same folder should automatically load it up using loadbang. The patch explains it all, too. Hope it helps.
oh and there’s a typo in the descriptive text next to the read message… it’s supposed to say "to be prompted to READ a file of your choosing"
I think it was because I’m used to puredata, which doesn’t have anything like the pattr objects as far as I know, that I got used to that jury-rigged system of storing sequences, but the autopattr object seems like the key to it all. thanks for the patch
I attached what became of my original sequencer just as an oddity, as you can see its pretty impractical with 3 channels. its fun anyway
Glad I could help.
If you did ever need to go back to your old patch or if, someday, you need to do something similar for any reason, then, although I’m not completely sure of this, you might need to use pattrhub with your pattr objects. pattrhub can centralize communication with pattr objects within the same patch/subpatch. I’m not sure based on the use of pattrhub/pattr how you would communicate to a top-level patch, but that would be a good place to start(check out the help-file for pattrhub, pattr, autopattr, pattrstorage, etc.)
Otherwise, you could drop multiple autopattr objects into subpatches and have one pattrstorage object in the top-level.
WillyC had a similar issue with this which you could read about in this thread:
But without my actually going through the trouble of reworking your patch entirely, it could just all be speculation…