pattr @bindto ::#1OP::#1led1
Sep 12 2013 | 11:29 pm
Im doing some work with pattrmarkers, and #1 is a part of the bindto directive.
A pattr object : pattr @bindto ::#1OP::#1led1
Do I really need to go through sprintfíng, constructing and concatenating to create the string\symbol with the #1 variable ?
- Sep 13 2013 | 8:23 amI guess one of the real questions I'm attempting to ask is how to get #1 to work in a main patch. Is there no provision for such a thing ?
- Sep 13 2013 | 8:33 amThe # variables are only available in subpar hers as far as I'm aware
- Sep 13 2013 | 8:34 amSubpatchers... Damn autocorrect
- Sep 13 2013 | 10:44 am:-)Well, I guess I'll have to create a naming structure tied to a loadbang\loadmess to create the bindto messages upon patch load.Anyone have any other ideas ?
- Sep 13 2013 | 11:45 amhm correct me if i'm stupid but if you have a main patch, you have it only once, right ? then why use #1 at all ?
- Sep 13 2013 | 1:47 pmGood question...
- Sep 13 2013 | 2:13 pmI would like to leave all the occurrences of #1 alone, and not have to modify them all when going back and forth between test scenarios. I like to be able to start small, and then build up into larger and larger through to completion, but there are modifications to the structure which happen along the way.Anyway, I have two fairly main patches, which are both abstractions that exist in my true main patch. Often, to test these two together (without the main patch), I load the two alone to get them working independently of the main patch while I make adjustments. When I do this, #1 does squat.It's a pain to have to keep going back and forth between the two scenarios. I would like a way to populate the #1's with a string of my own. I know it defaults to 0 for subpatches if there's no argument present, but that doesn't do anything for something if it's a main patch, even just for testing purposes.In the interim, I've created a larger structure than I would like using sprintf objects to take care of the bindto pattr attributes. I didn't know whether there was any way to send something to a thispatcher object or something to accomplish the #1.Maybe I'm just missing the obvious.
- Sep 13 2013 | 10:13 pmOkay, it now all makes sense ! i'm not sure if you're missing anything at all. I see how the situation you describe can quickly become a pain.hmmm now that i think of it, maybe you're missing "patcherargs" ? it requires maybe more programming than just #1 but it's really cleaner and iirc he behaves like a loadmess with default values that could be useful for the situation you describe ?
- Sep 14 2013 | 10:26 amThe documentation defines patcherargs as : "This object is useful inside abstractions, bpatchers, and subpatchers."Well, there you have it. :-)I guess what I need to do is to have a dummy patch just so my patchers can grow up to be subpatchers. :-PThere must be a "Best Practices" guide out there . . . anyone ? If not, then . . . me. :-)As I've committed to "JS in Max6" guide, I will also commit to a Max6 best practices. Don't know when, but it shall be done. I don't use Jitter or MSP, so I won't be writing on those parts, but I'll come out with something good and useful.
- Sep 14 2013 | 11:19 ammaybe the doc says so, but patcherargs still does send default parameters in a main patch :) better than do a dummy thing probalby no ?...
- Oct 11 2013 | 11:22 amThe ultimate outcome of this was to change how I work.What I now do is work from the main patch, and then r-click on the bpatcher or subpatcher, go to "Object," and then "New View of . . ." and work with that where the variables are in force, and where I have the ability to edit and save changes.Not what I expected, but it works fine.