On Mon, Feb 9, 2009 at 3:45 PM, Jonathan Wilkes <[email protected]> wrote: > I think it would make sense (both pedagogically and practically) if $0 in > message boxes actually _did_ something. Incrementing per message box would > be one option, but expanding to a user-defined symbol or float could be very > useful:
Actually, for me, I always think of the word "CONTEXT". An abstraction is one context, and the meanings of the $ args means one thing. While in a message, a $ arg means something completely different. Once I realized that the two are not the same thing, it made sense. If the $ args had the same meanings in both an abstraction and a message, there would be no way to create a message inside of an abstraction that allowed for $ args that were unrelated to the $ args in the abstraction. In other words, if they were the same thing, there would be no way to create a variable message that had more args than there were in the abstraction itself. Mike > > [loadbang] > | > [f $0] > | > [; set $0( > > That way, message box $0 is set by an incoming message: it then sets all > current (and future) message box $0's for the patch/abstraction. > Alternatively, you could use it for other stuff, like a substitution for > pd-my-complicated-and-tiresome-to-type-subpatch-name. > > abstraction $0: set by pd, unique abs instance identifier, common to all > object boxes > message box $0: set by user through msg box, common to all abstraction > instance msg's > > Seems like that would be consistent with the language as far as I understand > it. > > -Jonathan > > --- On Mon, 2/9/09, Matt Barber <[email protected]> wrote: > >> From: Matt Barber <[email protected]> >> Subject: Re: [PD] here I go again..dynamic abstractions >> To: "PD-List" <[email protected]> >> Date: Monday, February 9, 2009, 9:01 PM >> [f $0]-[message $1( is conceptually different from [message >> $0( for >> the same reason that [f $2]-[message $1( is conceptually >> different >> from [message $2( (and would be, even if $0 had any >> meaning in a >> message box). When I teach I always start with dollar-sign >> expansion >> in message-boxes, since it's simpler and easier to >> comprehend. Then >> when this issue comes up when they move to dollar-sign >> expansion in >> abstractions (and it always does come up), you can help >> them think it >> through with what they already know about message boxes. >> >> I only see two options: one is to use a different >> dereference symbol >> for abstraction arguments in message boxes -- but why worry >> with that >> since it's easy enough to get abstraction arguments >> into messages at >> "run-time?" -- the other is to make an exception >> and have special >> behavior for $0 in message boxes (that is, make it the same >> as in >> object boxes) -- but then this probably breaks the >> consistency of the >> language. >> >> >> Matt >> >> >> > Date: Mon, 09 Feb 2009 13:33:36 +0100 >> > From: Georg Werner <[email protected]> >> > Subject: Re: [PD] here I go again..dynamic >> abstractions >> > To: [email protected] >> > Message-ID: <[email protected]> >> > Content-Type: text/plain; charset=ISO-8859-1; >> format=flowed >> > >> > hi, >> > >> > Frank Barknecht: >> > > How about making $0 in messages be a message >> counter? >> > if somebody really needs that - i dont ;) >> > >> > ok, i give up. i think we are on a rather >> philosophical point now. >> > but i had a lot of times when students where asking >> why they have to >> > write [f $0]-[foobar $1( instead of [foobar $0(. so >> this came up from a >> > users point of view. >> > after getting all your input (thanks). i think Claude >> brought up the >> > most logical solution, because this makes the >> different functions of $ >> > obvious and obsolete. And it would help users and >> devs. (i know it will >> > be a long way - cause it will break some patches ... >> :( ) >> > > $ in message boxes is unfortunate. If there was >> a different symbol, >> > > perhaps #, you could combine both phases in one >> object box to avoid >> > > jumping through pointless hoops. >> > > [$0-#1-$2-#3( would be nice, but as Pd is now, >> it's a nightmare. >> > >> > not a nightmare, but this is one point why Pd is >> harder to learn for >> > beginners than it has to. >> > georg >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Garry Shandling - "I'm dating a woman now who, evidently, is unaware of it." _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
