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 ?

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

Subpatchers... Damn autocorrect

:-)

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 ?

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 ?

Good question...

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.

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 ?

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.

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

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.