[PD] Should message objects be able to pre-parse $0 into valid dollarzero?
Ivica Ico Bukvic
ico at vt.edu
Fri Sep 12 06:30:16 CEST 2014
On 9/10/2014 2:21 PM, Miller Puckette wrote:
> This leads to an interesting point - '$0' might recently have become more
> important than it was before because of the multiple-libpd-instances features
> in 0.46 - any libpd patch wanting to support multiple instances will need
> some $0-ish disambiguation.
>
> The recursion problem (that Ico asked about) is this... if a message box
> has to set the "cuttent" canvas to itself, so that its messages can access
> $0, and if its message leads to another message box in another canvas, that
> second message box can't just bash the value of "current canvas" but rather
> would have to save the previous one (and restore it when done) so that, when
> control returns to the first message box, any further messages it wishes to
> send get its own $0 and not the bashed one.
Thanks for the clarification, Miller. I am unfortunately not sure if I
fully understand how this constitutes a recursion. If the first message
has a $0 and you do setcurrent, and unset it immediately after the
message has been parsed, the canvas will not be set for the second
message. In addition, if the second message treats whatever $0 value
first one sent as its $1 argument, then there is no problem regardless
which canvas is set because the second message will be treating it as a
non-$0 argument. It seems to me this is more of a pd user error than the
semantics error but I may be very well missing something.
I guess the question I am not sure of is if inside a message_list (for
instance) one does:
canvas_setcurrent
binbuf_eval
canvas_unsetcurrent
Do the objects/traversal that the results of binbuf_eval are forwarded
to get evaluated before the unsetcurrent is invoked or is unsetcurrent
processed before the rest of the traversal is computed? If former, why
is this not affecting objects like [f $0] (or is it)?
>
> A deeper question bothers me: what about $1, etc, too? What if we're in an
> abstraction and want to 'speak' to $0 in our calling patch? THe usual way of
> doing that is for the calling patch to instantiate the abstraction with $0
> as an argument. Then the abstraction itself can access it as, say, $1. But
> that makes me think we need a way for the message box to be able to access $1
> as well as $0.
>
> It seems like this should either be something syntactic in messages themselves
> (that could have deep repercussions as that is at the very heart of everything),
> or else, perhaps, some kind of "properties" kludge, or perhaps (hopefully)
> there's a better way I haven't thought of.
This sounds like an interesting development but I am not sure if it
negates the immediate benefit of parsing $0 inside a message.
>
> Related: it would be nice if message boxs sprouted inlets for $ args ala Max.
> Even better if it could sprout multiple outlets so that one could send to
> multiple destinations without the need to use names at all. Even better if
> it could do tests and loops... oops, now we're writing a computer language.
> Should there be a 'generalized' message box that doesn't use binbuf_eval
> at all but rather gets a more spohisticated interpreter?
>
> Yet another possible direction: the new "text" object could be given a way to
> access the contents of message boxes, so that people could write their
> own semantics any way they please.
>
> Or externs could get some kind of pathway so that one could send message box
> strings to lua, etc.
>
> Hmm, time for another Pd convention :)
>
> M
>
> On Wed, Sep 10, 2014 at 10:23:06AM -0700, Phil Stone wrote:
>> I can add nothing of substance to this argument, but agree fully with Ivica.
>> In many years, I have yet to hear a convincing argument why $0 cannot be
>> recognized as the unique canvas identifier inside a message box. On the plus
>> side, it would eliminate a great deal of cruft hanging off of message boxes
>> used to kludge $0 into messages, something which occurs constantly, at least
>> in my patches.
>>
>>
>> Phil Stone
>> UC Davis
>>
>> On 9/10/14, 10:08 AM, Ivica Bukvic wrote:
>>> What about for instance arrays that should maintain scope inside a
>>> specific abstraction so that you can have multiple independent
>>> abstractions? $0 is very useful IMHO and is also necessary to stay due to
>>> backwards compatibility concerns. Therefore, I think the discussion should
>>> be limited to a simple yes or no for $0 substitution inside a message as
>>> it does not introduce a myriad of other questions.
>>>
>>> Having message recognize it as such (the code already seeks to resolve
>>> dollarzero but fails because the canvas was not set as current which
>>> should be a simple addition of a couple of lines of code) makes sense even
>>> if the only benefit is not having to do [$0] or what you are suggesting,
>>> namely [zerofy-me]. It is also worth noting that there is no reason why
>>> the two could not coexist.
>>>
>>> Yet, as it stands right now, $0, contrary to what has been already said in
>>> both threads on this topic, is an anomaly inside a message box and behaves
>>> like nothing else anywhere else in the code and as such this should be a
>>> no-brainer fix, just like having a trigger with static values, like [t 0 f
>>> 1] for opening a gate, passing a value, and then immediately closing it.
>>> This is what pd-l2ork does (and so does Max). So, rather than putting
>>> redundant messages with static values below the [t b] outlet, one object
>>> solves it all. To me this is the same situation where message can do it
>>> all, and if that makes my patching quicker, I am all for it.
>>>
>>> On Sep 10, 2014 12:48 PM, "Jonathan Wilkes" <jancsika at yahoo.com
>>> <mailto:jancsika at yahoo.com>> wrote:
>>>
>>> Two things:
>>>
>>> 1) the lack of "$0" in messages is only a symptom of a bigger
>>> problem with scope of binding symbols in Pd. I'd rather see new
>>> objects (or wrapper objects) that handle scope in a sensible
>>> manner which doesn't require typing "$0-" at all. There's already
>>> no need for $0 in your preset_hub/node design. Why not extend the
>>> hub/node idea and get rid of the need for $0 completely?
>>>
>>> [hub]/[node] = [send]/[receive]
>>> [hub~]/[node~] = [throw~]/[catch~]
>>> etc.
>>>
>>> 2) On a more superficial note, isn't the problem that Pd doesn't
>>> store stray "\n" characters in message boxes? The only time I can
>>> think of when one would have a real desire for $0 in a message box
>>> is when initializing a bunch of receivers:
>>>
>>> [; $0-foo 1;
>>> $0-bar 2;
>>> $0-flub 3;(
>>>
>>> But if the box stored "\n" you could get the same clean format
>>> with commas:
>>> [foo 1,
>>> bar 2,
>>> flub 3(
>>> |
>>> [zerofy-me] <- add a "$0-" to the selector
>>> | |
>>> [send]
>>>
>>> No ugly zeros, no leading semi-colon, everybody wins!
>>>
>>> -Jonathan
>>>
>>>
>>> On Wednesday, September 10, 2014 2:27 AM, Ivica Bukvic <ico at vt.edu
>>> <mailto:ico at vt.edu>> wrote:
>>>
>>>
>>>
>>> On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris at mccormick.cx
>>> <mailto:chris at mccormick.cx>> wrote:
>>> >
>>> > Hi Ivica,
>>> >
>>> > On 10/09/14 04:19, Ivica Ico Bukvic wrote:
>>> > > Yet, I wonder why message shouldn't be able to pre-parse $0
>>> into a valid
>>> > > dollarzero (canvas instance), when there will never be a
>>> message one
>>> > >
>>> > > Thoughts?
>>> >
>>> > There has been a lot of discussion regarding this over the years
>>> which
>>> > might be good to read to get an idea on the different
>>> > philosophical/language design issues:
>>> >
>>> >
>>> <http://comments.gmane.org/gmane.comp.multimedia.puredata.general/56365>
>>> Thanks, Chris, for bringing this to my attention. Since one of
>>> Miller's core ideas behind pd is absolute backwards compatibility,
>>> most of alternatives suggested in that thread would cause
>>> unacceptable breakage with backwards compatibility or a really
>>> kludge workaround for the support of legacy patches. It seems to
>>> me Phil really has a point I completely agree with. FWIW, I am
>>> looking to implement this in pd-l2ork and as soon as I get a
>>> better idea about the recursion Miller mentioned and how to
>>> circumvent it, it should find its way into pd-l2ork's source.
>>> Best,
>>> Ico
>>> >
>>> > Cheers,
>>> >
>>> > Chris.
>>> >
>>> > --
>>> > http://mccormick.cx/
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>> --
>> Phil Stone
>> Programmer - Application Development Team
>> Information Technology
>> UC Davis School of Veterinary Medicine
>> 530-752-5282 (o)
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
More information about the Pd-list
mailing list