Forums > MaxMSP

pattr @bindto ::#1OP::#1led1

September 12, 2013 | 4: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 ?


September 13, 2013 | 1:23 am

I 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 ?



Lee
September 13, 2013 | 1:33 am

The # variables are only available in subpar hers as far as I’m aware



Lee
September 13, 2013 | 1:34 am

Subpatchers… Damn autocorrect


September 13, 2013 | 3: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 ?


September 13, 2013 | 4:45 am

hm 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 ?


September 13, 2013 | 6:47 am

Good question…


September 13, 2013 | 7:13 am

I 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.


September 13, 2013 | 3:13 pm

Okay, 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 ?


September 14, 2013 | 3:26 am

The 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. :-P

There 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.


September 14, 2013 | 4:19 am

maybe the doc says so, but patcherargs still does send default parameters in a main patch :) better than do a dummy thing probalby no ?…


October 11, 2013 | 4:22 am

The 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.


Viewing 12 posts - 1 through 12 (of 12 total)