Miller et al,
The current code suggests that this should happen (binbuf_eval calls the appropriate function), but since canvas_setcurrent is never called, it fails and returns 0.
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 could send into it that could trump this argument (how would one specify an argument $0 anyhow)? I do understand that message is not meant to pre-parse values, but shouldn't this be an exception? That way one creating a message with an instance included does not have to go through the trouble of creating an [$0] object that needs to be packed with the rest of the list and then forwarded onward to a message object.
Thoughts?
If others are in favor of this idea, should this take place for all types of messages passed into message object (bang, list, anything, blob, etc.)?
I think it would be easy enough to implement (message boxes would simply save $0 and put it somewhere when the message was getting passed - with some ugliness about recursion to worry about.)
But I'd like to find a solution that somehow allows accessing $1, etc, from either context. I can't find a good design that would accomodate this. (And as always, when I can't think of a good design, I simply work on something else instead hoping I or someone else will think of something good in the future :)
M
On Tue, Sep 09, 2014 at 04:19:10PM -0400, Ivica Ico Bukvic wrote:
Miller et al,
The current code suggests that this should happen (binbuf_eval calls the appropriate function), but since canvas_setcurrent is never called, it fails and returns 0.
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 could send into it that could trump this argument (how would one specify an argument $0 anyhow)? I do understand that message is not meant to pre-parse values, but shouldn't this be an exception? That way one creating a message with an instance included does not have to go through the trouble of creating an [$0] object that needs to be packed with the rest of the list and then forwarded onward to a message object.
Thoughts?
If others are in favor of this idea, should this take place for all types of messages passed into message object (bang, list, anything, blob, etc.)?
-- 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@vt.edu www.performingarts.vt.edu disis.music.vt.edu l2ork.music.vt.edu
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 09/09/2014 06:13 PM, Miller Puckette wrote:
I think it would be easy enough to implement (message boxes would simply save $0 and put it somewhere when the message was getting passed - with some ugliness about recursion to worry about.)
Can you give me an example of such a recursion so that I can try to think of a solution?
But I'd like to find a solution that somehow allows accessing $1, etc, from either context. I can't find a good design that would accomodate this. (And as always, when I can't think of a good design, I simply work on something else instead hoping I or someone else will think of something good in the future :)
M
On Tue, Sep 09, 2014 at 04:19:10PM -0400, Ivica Ico Bukvic wrote:
Miller et al,
The current code suggests that this should happen (binbuf_eval calls the appropriate function), but since canvas_setcurrent is never called, it fails and returns 0.
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 could send into it that could trump this argument (how would one specify an argument $0 anyhow)? I do understand that message is not meant to pre-parse values, but shouldn't this be an exception? That way one creating a message with an instance included does not have to go through the trouble of creating an [$0] object that needs to be packed with the rest of the list and then forwarded onward to a message object.
Thoughts?
If others are in favor of this idea, should this take place for all types of messages passed into message object (bang, list, anything, blob, etc.)?
-- 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@vt.edu www.performingarts.vt.edu disis.music.vt.edu l2ork.music.vt.edu
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
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
Cheers,
Chris.
On Sep 10, 2014 1:17 AM, "Chris McCormick" chris@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.
Two things:
- 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.
- 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@vt.edu wrote:
On Sep 10, 2014 1:17 AM, "Chris McCormick" chris@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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@yahoo.com wrote:
Two things:
- 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.
- 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@vt.edu wrote:
On Sep 10, 2014 1:17 AM, "Chris McCormick" chris@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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@yahoo.com mailto:jancsika@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@vt.edu <mailto:ico@vt.edu>> wrote: On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris@mccormick.cx <mailto:chris@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@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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.
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@yahoo.com mailto:jancsika@yahoo.com> wrote:
Two things:
- 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.
- 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@vt.edu mailto:ico@vt.edu> wrote:
On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris@mccormick.cx mailto:chris@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.
Pd-list@lists.iem.at mailto:Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/10/2014 02: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.
Scope hygiene and namespace management was one of the main issues that led me to start working on MFP [1]. While my code base is totally different from PD's, I think the approach I came up with for this works pretty well and is at least a proof-of-concept that hints that working this stuff out in PD will make for cleaner patches.
I don't think there's enough overlap in the implementation for a detailed description to be useful, but the highlights are: The app knows about lexical scopes. Every patch has at least one scope and possibly more (nested scopes are possible, UI is a bit kludgy). Any time a name is created (by naming an object in a patch, or by creating an [r] object) it goes into a specific scope. Trying to resolve names, by creating an [s] for example, searches in the local scope of the [s] first, then works upward. There are always-available names ("patch", "self", "app") which resolve to the patch, the object containing the name reference, and the top-level program respectively. Names can include explicit tree-walking to target an object in a scope that's not a parent of the current scope (i.e. [s someotherpatch.scopename.name])
With this approach there's no need for $0 or anything like it. Names are local to the object in which they were created. The whole thing is still young, but I am finding that patches have a lot less name-mangling and are a lot more readable to my programmer's eyes.
As a bonus, with clean scope semantics you can pretty easily create user
patches that have dynamic (per-instance) numbers of inlets and outlets,
with fairly arbitrary semantics about how the templating and cloning of
patch-pieces works. The trick is "hygienic scope cloning"... take all
the objects in a scope, copy them into a new scope within the patch.
This lets you use [s] and [r] within portions of a patch that need to be
cut-n-pasted to add more inlets/outlets, and have everything Just Work.
Last I looked, this was pretty hard to do in PD.
Thanks, Bill Gribble
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@yahoo.com mailto:jancsika@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@vt.edu <mailto:ico@vt.edu>> wrote: On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris@mccormick.cx <mailto:chris@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes I agree the two ideas may coexist. But I also think that if the two were to coexist, $0 in message boxes would pale in comparison in terms of usability.
Hub/node: make a hub on a canvas. Now every node you create on that canvas or subcanvas belongs to that hub. If you need more than one, give them names.
$0: prepend a string with this to make a special name that is unique to a canvas and its subpatches (but not abstractions created in either). The dollarsign variable will be filled in at the time the patch is created, and given a unique value in the running Pd instance. If you want a name inside an abstraction to share the $0 with its parent, just send $0 as an abstraction argument, then use the corresponding argument number inside the abstraction to retrieve the value of the parent $0.
I mean, if you can solve $0 in message boxes in a few hours or so then go ahead and do it. But if it brings up any issues that require workarounds I think the time would be better spent on building out more hub/node infrastructure. (And they don't necessarily need to have that name, I'm just using it as a placeholder.)
Btw-- I just heard yesterday from someone using Max/MSP about something like using a "#0-" prefixes to hack local scope for receive symbols. Is this still the case there, too?
-Jonathan
On Wednesday, September 10, 2014 1:08 PM, Ivica Bukvic ico@vt.edu 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@yahoo.com wrote:
Two things:
- 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.
- 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@vt.edu wrote:
On Sep 10, 2014 1:17 AM, "Chris McCormick" chris@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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 9/11/2014 1:05 PM, Jonathan Wilkes wrote:
Yes I agree the two ideas may coexist. But I also think that if the two were to coexist, $0 in message boxes would pale in comparison in terms of usability.
Hub/node: make a hub on a canvas. Now every node you create on that canvas or subcanvas belongs to that hub. If you need more than one, give them names.
$0: prepend a string with this to make a special name that is unique to a canvas and its subpatches (but not abstractions created in either). The dollarsign variable will be filled in at the time the patch is created, and given a unique value in the running Pd instance. If you want a name inside an abstraction to share the $0 with its parent, just send $0 as an abstraction argument, then use the corresponding argument number inside the abstraction to retrieve the value of the parent $0.
I mean, if you can solve $0 in message boxes in a few hours or so then go ahead and do it. But if it brings up any
Not hours, but rather minutes. That is, unless I am missing something... Still not sure, if I fully understood Miller's explanation (see my response).
issues that require workarounds I think the time would be better spent on building out more hub/node infrastructure. (And they don't necessarily need to have that name, I'm just using it as a placeholder.)
Btw-- I just heard yesterday from someone using Max/MSP about something like using a "#0-" prefixes to hack local scope for receive symbols. Is this still the case there, too?
Very much so.
-Jonathan
On Wednesday, September 10, 2014 1:08 PM, Ivica Bukvic ico@vt.edu 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@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@vt.edu> wrote: On Sep 10, 2014 1:17 AM, "Chris McCormick" <chris@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
what about using a new symbol altogether for message boxes to pass creation arguments and $0 value?
maybe @0. @1, etc???
That's not a bad idea, but I think it would have to be a construction that wouldn't break backwards compatibility.
I suppose I can't think of an obvious case where something like @1 would currently be used inside a message box. But with backwards compatibility an accumulation of edge cases can be just as frustrating as breaking obvious cases. Also, the fact that these variables would be able to get expanded within a string makes more edge cases likely.
-Jonathan
On Friday, September 12, 2014 5:36 AM, i go bananas hard.off@gmail.com wrote:
what about using a new symbol altogether for message boxes to pass creation arguments and $0 value?
maybe @0. @1, etc???
not sure if this helps and not sure what you guys are talking about but once I figured out how to use the same control for different objects I found that that did not work, the switching of the control to update a different object works great but since my synth used the controls as a storage object for the actual initialization as in a model view controller type thing, i found that when a control was switched to say point to envelope2 that envelope2 was not initialized so I have been back at the drawing board. http://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-message...
On Fri, Sep 12, 2014 at 1:31 PM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
That's not a bad idea, but I think it would have to be a construction that wouldn't break backwards compatibility.
I suppose I can't think of an obvious case where something like @1 would currently be used inside a message box. But with backwards compatibility an accumulation of edge cases can be just as frustrating as breaking obvious cases. Also, the fact that these variables would be able to get expanded within a string makes more edge cases likely.
-Jonathan
On Friday, September 12, 2014 5:36 AM, i go bananas hard.off@gmail.com wrote:
what about using a new symbol altogether for message boxes to pass creation arguments and $0 value?
maybe @0. @1, etc???
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Bill Gribble -
Billy Stiltner -
Chris McCormick -
i go bananas -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
Miller Puckette -
Phil Stone