Forums > MaxMSP

Feature Request: Help me organize complex patcher hierarchies

July 6, 2007 | 9:28 am

I’ve been repeatedly wishing for two features lately:

1) Provide send/receive functionality that has private scoping like pv. I’m picturing either the introduction of a "private" argument to send/receive, or an "immediate" argument to pv that allows pv to output immediately instead of waiting for a bang.

I know there are tricks like using the #0 argument, and Mattijs has done some interesting javascript-based work in this area, but honestly these are kludegy workarounds to a deficiency in Max. Sorry I don’t mean to be harsh or insulting – I just think this is a basic missing feature needed for constructing complicated patches that can be instantiated multiple times without interfering with one another.

2) Allow pvar to reference objects outside of the current patch. I specifically want to use the parent:: syntax so pvar can be encapsulated.

In some ways this functionality is available via a pattr bound to parent::guiObjectName, but this disrupts the nicely structured pattr hierarchy I am trying to set up. I don’t want to encapsulate my pattrs because I drop pattrforwards into my top level patcher to arbitrarily connect midi controllers to various parts of my patch, and I want to use intuitive naming conventions (delay::feedback instead of delay::guiControls::feedback). I could introduce additional pattrs just for controlling the gui objects, but then I have to deal with managing which pattrs are active and inactive, which isn’t trivial in large patcher hierarchies where I’m dropping in bpatchers on the fly.

Those alternatives aside, I’ve found pvar is a great tool for separating gui from process logic. Gui logic is often a good candidate for encapsulation, so it’s a shame I can’t encapsulate an integral part of that logic (the pvar object).

If this feature is added it would be fantastic if encapsulating pvar automatically prepended parent:: to the pvar argument when applicable (when the pvar is encapsulated without the referenced gui object). I know I’m lazy, but the existence of autopattr seems to indicate that C74 occasionally tailors to laziness ;)

I know a lot of this been asked for before, so thanks for listening.
Adam


July 6, 2007 | 10:16 am

What can I say? I agree completely and I like the clear way you put it.

I don’t advise to use the javascript work I did on this so far. JS in Max has not proven to be up to a task of this scale.

FWIW, the ‘how to apply oo in max’ thread has continued off-list between John and me and we’re making some gorgeous progress towards a small set of externals that apply directly to the fundamental problem that you describe.

Perhaps in the long run these new externals can convince cycling to embed a similar system in max?

Best,
Mattijs

Quote: adamj wrote on Fri, 06 July 2007 11:28
—————————————————-
> I know there are tricks like using the #0 argument, and Mattijs has done some interesting javascript-based work in this area, but honestly these are kludegy workarounds to a deficiency in Max. Sorry I don’t mean to be harsh or insulting – I just think this is a basic missing feature needed for constructing complicated patches that can be instantiated multiple times without interfering with one another.
>


July 6, 2007 | 2:44 pm

"Those alternatives aside, I’ve found pvar is a great tool for separating gui from process logic. Gui logic is often a good candidate for encapsulation, so it’s a shame I can’t encapsulate an integral part of that logic (the pvar object)."

Amen brotha! I have been wanting this for so long. The fact
that pvar does not work in sub patchers, actually increases the
clutter in my patches because it does not allow me to
encapsulate. And pattr does not allow me to specify the
number of inlets so I can not replace pvars with pattrs!

Anthony


July 7, 2007 | 10:08 am

Anthony Palomba schrieb:
> And pattr does not allow me to specify the number of inlets so I can
> not replace pvars with pattrs!

Yeah, it seems a simple pattrbackward could do the trick, but it hasn’t
arrived yet. I know that the demand is recognized though. Might be hard
to implement, lets see what Max 5 will give us…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


July 7, 2007 | 10:18 am

I can’t help but laughing, since I remember the arguments I had with my co-workers, as it was suggested to me that an autopattr object might make some people happy. Let’s just say that laziness was not part of the initial design of the system. :)

jb

Quote: adamj wrote on Fri, 06 July 2007 11:28
—————————————————-
I know I’m lazy, but the existence of autopattr seems to indicate that C74 occasionally tailors to laziness ;)



_j
July 7, 2007 | 10:29 am

its not just send and receive, its variables too y’know. as #0 only works in abstractions it requires a lot of foresight if you plan on opening the same patch multiple times. i do wish for a more private version of send and receive as you have stated. And I think being able to add a pvar into a subpatch and read from a parent would be pretty cool. But then again, it is possible to just hook up a send to whatever UI element you have and then make it invisible. It does the same its just less elegant.


July 7, 2007 | 1:08 pm

autopattr did make me happy but, like the preset object, it is best when
introduced late in the design of a patch when the patch is debugged and and
design issues are settled. Being too hasty to store things can make for a
lot of work if you add features to your patch.

On 7/7/07 6:18 AM, "Jeremy Bernstein" wrote:

>
> I can’t help but laughing, since I remember the arguments I had with my
> co-workers, as it was suggested to me that an autopattr object might make some
> people happy. Let’s just say that laziness was not part of the initial design
> of the system. :)
>
> jb
>
> Quote: adamj wrote on Fri, 06 July 2007 11:28
> —————————————————-
> I know I’m lazy, but the existence of autopattr seems to indicate that C74
> occasionally tailors to laziness ;)
>
>

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


July 7, 2007 | 4:18 pm

At 12:18 PM +0200 7/7/07, Jeremy Bernstein wrote:
>I can’t help but laughing, since I remember the arguments I had with my co-workers, as it was suggested to me that an autopattr object might make some people happy. Let’s just say that laziness was not part of the initial design of the system. :)

I, for one, never used the pre-autopattr pattr world. It seemed like the complexity was too great, and I might as well build my own storage systems w/ coll. Once I discovered autopattr though, I realized that there was no way I could build a system as easy as using autopattr & pattrstorage. I started looking for a new hobby to fill all the free time I was going to have now that I was using pattr. :-)

-C


Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." – Brian Eno


July 8, 2007 | 11:01 pm

An update from my perspective: as Mattijs said, it’s being worked on, though what we have is not part of the pattr system, and doesn’t use pattr syntax (my version can be recompiled to use object:method rather than object.method if desired).

I’m a little busy to work on my version much at present, but in its current state it implements public/private objects (patcher, abstraction, bpatcher or poly~) containing public/private methods that can return a message to the caller.

Calls to methods are scope-checked at first call, using top-down global syntax (:object.object.method), scope-relative local syntax (object.object.method), or scope-relative parent syntax (..object.object.method).

Mattijs has suggested not implementing a public/private variable object as such, instead simply defining a method that sets/gets any suitable int, float, list or symbol storage object, and calling to that from wherever it’s needed. I’m warming to this idea.

I’ve recently implemented the system entirely as externals rather than using abstractions, and method call/return are now very efficient, similar to using just send/receive.

Some work needs to be done between Mattijs and myself to merge our somewhat divergent ideas, with better agreement on scoping and naming conventions. I’d be reluctant to make anything available until we have that locked down.

But we’re getting there…


July 10, 2007 | 7:12 am

Jeremy Bernstein schrieb:
> I can’t help but laughing, since I remember the arguments I had with
> my co-workers, as it was suggested to me that an autopattr object
> might make some people happy. Let’s just say that laziness was not
> part of the initial design of the system. :)

Laziness is the main reason for the existence of software… Too lazy to
calculate? let a program do it, too lazy to modify 2000 mails headers?
go and learn regular expressions…
Too lazy to patch?, get a pattrbackward to help out…

Anything which I have to do repeatedly can be a target for my laziness,
I’ll spend hours to automate it. And then one push of a button and it
does all by itself… (It won’t speed up things the first time, but
every other time a lot…)

Without autopattr, I guess only one 50th of the people who use the pattr
system now, would actually use it… Its maybe the most beautiful part
of it.


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


July 10, 2007 | 4:25 pm

Quote: Stefan Tiedje wrote on Tue, 10 July 2007 00:12
—————————————————-
> Laziness is the main reason for the existence of software
> …
> Anything which I have to do repeatedly can be a target for my laziness,
> I’ll spend hours to automate it. And then one push of a button and it
> does all by itself…

Yup, this is my perspective too. Don’t get me wrong, I wasn’t trying to put autopattr down with the laziness comment. In my mind, convenience usually equates to usability and/or usefulness. Convenience (which allows me to be "lazy") is a really good thing especially in software the complexity of Max.

I think my comment about how "C74 occasionally tailors to laziness" was partially inspired by the help file for autopattr, which says "freeing pattr users from the burdens of thought". That always makes me laugh. Thinking is such a burden ;)

Adam


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