According to [namecanvas] help, this object is obsolete? How else can one send a message to one and only one abstraction without using namecanvas? Is there the concept of 'this'?
The example below will send a message to all patchname.pd abstractions, this is not what I think most require:
[message( | [s pd-patchname.pd]
On Wed, Sep 29, 2010 at 10:30 PM, brandon zeeb zeeb.brandon@gmail.comwrote:
Oh, that is awesome! Thanks a bunch for compiling these for me.
Going to have some fun tonight...
~B
On Wed, Sep 29, 2010 at 10:13 PM, Jonathan Wilkes jancsika@yahoo.comwrote:
You can create [namecanvas $0-foo] in the relevant canvas, then [message( | [s $0-foo]
You can also send a message to a named subpatch like [pd foo] by prefixing the subpatch name with "pd-" like this:
[message( | [s pd-foo]
And finally, send to an abstraction or open patch (globally) by using:
[message( | [s pd-patchname.pd]
I'm not sure if the "pd-" prefix is explicitly documented anywhere-- I only remember seeing it in passing with reference to traversing scalars. Maybe it could be added to doc/manuals/pd-msg, then have a link to that from canvas-help.pd.
-Jonathan
--- On *Thu, 9/30/10, brandon zeeb zeeb.brandon@gmail.com* wrote:
From: brandon zeeb zeeb.brandon@gmail.com Subject: Re: [PD] Dynamic Graph on Parent
To: "PD List" pd-list@iem.at Date: Thursday, September 30, 2010, 3:53 AM
How is this sent to the current patch? Can you give me a quick example.
Thanks ~B
On Wed, Sep 29, 2010 at 4:41 PM, Jonathan Wilkes <jancsika@yahoo.comhttp://mc/compose?to=jancsika@yahoo.com
wrote:
A canvas accepts a "donecanvasdialog" message that can be used to do what you want. Search the list for that.
There's also the "coords" message, which takes its arguments in a different order than "donecanvasdialog" and doesn't set the dirty flag for Pd < 0.43. Other than that I'm not sure what the differences are between the two messages.
-Jonathan
--- On *Wed, 9/29/10, brandon zeeb <zeeb.brandon@gmail.comhttp://mc/compose?to=zeeb.brandon@gmail.com
- wrote:
From: brandon zeeb <zeeb.brandon@gmail.comhttp://mc/compose?to=zeeb.brandon@gmail.com
Subject: [PD] Dynamic Graph on Parent To: "PD List" <pd-list@iem.at http://mc/compose?to=pd-list@iem.at> Date: Wednesday, September 29, 2010, 10:08 PM
Is there a way to dynamically adjust and enabled graph on parent (GOP)? I'm building some UI sequencer widgets and it would be preferable to dynamically adjust the GOP size given user input, say number of steps in a step sequencer (ie: an 8x8 vs a 16x16 step sequencer using the same abstraction).
If this is documented anywhere a link to the docs will suffice, I'm unable to find any.
Thanks, ~Brandon
-----Inline Attachment Follows-----
Pd-list@iem.at http://mc/compose?to=Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----Inline Attachment Follows-----
Pd-list@iem.at http://mc/compose?to=Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-09-30 09:02, brandon zeeb wrote:
According to [namecanvas] help, this object is obsolete? How else can one send a message to one and only one abstraction without using namecanvas? Is there the concept of 'this'?
"iemguts" kind of introduces a concept of "this". most of the objects work on either "this" or "parent of this" or some other "direct ancestor of this".
otoh, pd itself never actively supported dynamic patching.
iirc, the reason for obsoleting [namecanvas] is that it allows the dynamic patching engine to get into an inconsistent (probably crashing) state (true, there are other things that allow this as well, without getting obsoleted).
anyhow, [namecanvas] has no concept of "this" either.
fgmadsr IOhannes
What I'm seeing here is basically there is no currently supported way in vanilla pd to adjust GOP properties for a particular abstraction (not globally)? If so, this is rather upsetting :(
~Brandon
On Thu, Sep 30, 2010 at 3:11 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
On 2010-09-30 09:02, brandon zeeb wrote:
According to [namecanvas] help, this object is obsolete? How else can
one
send a message to one and only one abstraction without using namecanvas?
Is
there the concept of 'this'?
"iemguts" kind of introduces a concept of "this". most of the objects work on either "this" or "parent of this" or some other "direct ancestor of this".
otoh, pd itself never actively supported dynamic patching.
iirc, the reason for obsoleting [namecanvas] is that it allows the dynamic patching engine to get into an inconsistent (probably crashing) state (true, there are other things that allow this as well, without getting obsoleted).
anyhow, [namecanvas] has no concept of "this" either.
fgmadsr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-09-30 11:31, brandon zeeb wrote:
What I'm seeing here is basically there is no currently supported way in vanilla pd to adjust GOP properties for a particular abstraction (not globally)? If so, this is rather upsetting :(
no it's not. there is currently zero "supported" way to do anything dynamically. but people still do: chances are near to zero, that the unsupported feature for dynamic patching will go away in this century.
the same goes for [namecanvas]. it has been flagged "deprecated" in the help-patch for about 5 years or so. therefore: just use it :-)
fgmasdr IOhannes
On 2010-09-30 11:35, IOhannes m zmoelnig wrote:
the same goes for [namecanvas].
for the sake of completeness: one of the earlier mails on the topic of obsoleted [namecanvas] can be found here:
http://lists.puredata.info/pipermail/pd-dev/2004-12/003419.html
On Thu, 30 Sep 2010, brandon zeeb wrote:
What I'm seeing here is basically there is no currently supported way in vanilla pd to adjust GOP properties for a particular abstraction (not globally)? If so, this is rather upsetting :(
In Pd's dynamic patching you have to put up with Miller telling you that dynamic patching is not really supported, while the rest of the people use dynamic patching on a daily basis. Get used to it, and don't worry. Dynamic patching can't possibly disappear at this point. It's not the only part of Pd that is said that it could change at any time, but haven't really changed since Pd 35 or so.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Dynamic patching is one of the best thing PD has going for it. Without the ability to dynamically construct abstraction content, PD is an effort in extreme manual labor, and as a software developer, I disagree with the concept of manual labor.
On Thu, Sep 30, 2010 at 8:14 AM, Mathieu Bouchard matju@artengine.cawrote:
In Pd's dynamic patching you have to put up with Miller telling you that dynamic patching is not really supported, while the rest of the people use dynamic patching on a daily basis. Get used to it, and don't worry. Dynamic patching can't possibly disappear at this point. It's not the only part of Pd that is said that it could change at any time, but haven't really changed since Pd 35 or so.
On Thu, 30 Sep 2010, IOhannes m zmoelnig wrote:
iirc, the reason for obsoleting [namecanvas] is that it allows the dynamic patching engine to get into an inconsistent (probably crashing) state (true, there are other things that allow this as well, without getting obsoleted).
Especially, you can crash pd using the thing that is supposed to be replacing namecanvas, using a total of 3 objects. So, the reason for obsoleting [namecanvas] is bogus. Here's an attachment for demonstrating that.
anyhow, [namecanvas] has no concept of "this" either.
What's a concept of "this", to you ? It seems that we don't agree on this... we're not using the same vocabulary.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
http://lists.puredata.info/pipermail/pd-dev/2004-12/003428.html
Essentially, being able to send a message to the current canvas in vanilla-pd without naming it, "this" in the current context is similar to the Java concept of "this".
If Miller wants to remove [namecanvas], just give us a "this" expression! What about $! ?
~Brandon
On Thu, Sep 30, 2010 at 8:13 AM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 30 Sep 2010, IOhannes m zmoelnig wrote:
iirc, the reason for obsoleting [namecanvas] is that it allows the dynamic
patching engine to get into an inconsistent (probably crashing) state (true, there are other things that allow this as well, without getting obsoleted).
Especially, you can crash pd using the thing that is supposed to be replacing namecanvas, using a total of 3 objects. So, the reason for obsoleting [namecanvas] is bogus. Here's an attachment for demonstrating that.
anyhow, [namecanvas] has no concept of "this" either.
What's a concept of "this", to you ? It seems that we don't agree on this... we're not using the same vocabulary.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 30 Sep 2010, brandon zeeb wrote:
If Miller wants to remove [namecanvas], just give us a "this" expression! What about $! ?
What would be the type of $! ?
I don't think that there is any atom-type for supporting the feature that you suggest.
see also http://lists.puredata.info/pipermail/pd-list/2006-02/035454.html
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
In my happy world, one could perform the following:
[coords 0 -1 1 1 80 90 1 100 100;( | | [s $!]
With the example above, one could perform canvas operations on the current canvas, ie: "this". So to answer your question, $! would be the equivalent to whatever name you supplied in [namecanvas], so it's type would be that of the canvas, an object type.
Therefore, if you attempted the following, no error should occur (again, in my happy world)
[clear( | | [s $1]
Miller?
Cheers, ~Brandon
On Thu, Sep 30, 2010 at 1:22 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 30 Sep 2010, brandon zeeb wrote:
If Miller wants to remove [namecanvas], just give us a "this" expression!
What about $! ?
What would be the type of $! ?
I don't think that there is any atom-type for supporting the feature that you suggest.
see also http://lists.puredata.info/pipermail/pd-list/2006-02/035454.html
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Sorry, that last example should read: [clear( | | [s $!]
On Thu, Sep 30, 2010 at 1:42 PM, brandon zeeb zeeb.brandon@gmail.comwrote:
In my happy world, one could perform the following:
[coords 0 -1 1 1 80 90 1 100 100;( | | [s $!]
With the example above, one could perform canvas operations on the current canvas, ie: "this". So to answer your question, $! would be the equivalent to whatever name you supplied in [namecanvas], so it's type would be that of the canvas, an object type.
Therefore, if you attempted the following, no error should occur (again, in my happy world)
[clear( | | [s $1]
Miller?
Cheers, ~Brandon
On Thu, Sep 30, 2010 at 1:22 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 30 Sep 2010, brandon zeeb wrote:
If Miller wants to remove [namecanvas], just give us a "this" expression!
What about $! ?
What would be the type of $! ?
I don't think that there is any atom-type for supporting the feature that you suggest.
see also http://lists.puredata.info/pipermail/pd-list/2006-02/035454.html
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On 2010-09-30 19:42, brandon zeeb wrote:
Sorry, that last example should read: [clear( | | [s $!]
you can do this with iemguts.
true, this is not vanilla. but one of the strengths of Pd is, that you can do a lot with externals. so why should you refuse to use them?
fgmasdr IOhannes
On Thu, 30 Sep 2010, brandon zeeb wrote:
With the example above, one could perform canvas operations on the current canvas, ie: "this". So to answer your question, $! would be the equivalent to whatever name you supplied in [namecanvas], so it's type would be that of the canvas, an object type.
There's no atomtype for that.
A_SYMBOL can only refer to a t_symbol (a normal symbol entry), which contains the receive-symbol info, so, a unique receive-symbol has to be registered if you want to use that. I mean, it's very doable and easy to add an extra pd_bind to each canvas, that would be "$0-canvas" or "$0-this" or whatever, but it's another feature, and it's one that you have to add before adding $!, because the value of $! depends on it... and then you don't really need $! because you can write $0-canvas instead.
A_POINTER can only point to "scalars" and elements of "array", not to any objects.
$-substitution can only ever mean something that could theoretically have come out of an object : I mean that $-substitution first makes a new message, and THEN another part of pd looks at what it means. So, $! can't be too special, it has to rest upon other features of pd.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Thu, 30 Sep 2010, brandon zeeb wrote:
According to [namecanvas] help, this object is obsolete? How else can one send a message to one and only one abstraction without using namecanvas?
I repeated this over and over for years, but Miller isn't listening. He won't listen to you either.
If [namecanvas] ever disappears, it will be replaced by 10 externals of the same name within the next 10 minutes, because people really need it. And it will be a relief because it won't be written "OBSOLETE" all over them.
On Thu, 30 Sep 2010, IOhannes m zmoelnig wrote:
"iemguts" kind of introduces a concept of "this".
It's not a concept of "this" as brandon wants it because it's not a receive-symbol. In iemguts, what is being used is a number that is the number of canvases to be climbed up the hierarchy : so, to get from a subpatch of a subpatch of an abstraction, to the parent of the abstraction, it takes the number 3.
GridFlow has several iemguts-like classes introduced in late 2009, which use this same numbering, but there's no replacement of [namecanvas].
most of the objects work on either "this" or "parent of this" or some other "direct ancestor of this".
I'm beginning to see uses for accessing a "child of this" with iemguts-like externals, but it just can't be done with that numbering scheme, so, I'm still not doing it.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On 2010-09-30 13:59, Mathieu Bouchard wrote:
It's not a concept of "this" as brandon wants it because it's not a receive-symbol. In iemguts, what is being used is a number that is the number of canvases to be climbed up the hierarchy : so, to get from a subpatch of a subpatch of an abstraction, to the parent of the abstraction, it takes the number 3.
do you mean [sendcanvas 3] would fullfill brandon's requirements?
fgamsdr IOhannes
On Thu, 30 Sep 2010, IOhannes m zmoelnig wrote:
On 2010-09-30 13:59, Mathieu Bouchard wrote:
It's not a concept of "this" as brandon wants it because it's not a receive-symbol. In iemguts, what is being used is a number that is the number of canvases to be climbed up the hierarchy : so, to get from a subpatch of a subpatch of an abstraction, to the parent of the abstraction, it takes the number 3.
do you mean [sendcanvas 3] would fullfill brandon's requirements?
I mean [sendcanvas 0] would fulfill them, and with a different argument, it can serve different purposes.
I just cloned it as [gf/canvas_send]. It's in the upcoming GridFlow 9.12.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
--- On Sun, 10/3/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] namecanvas obsolete? Why? Re: Dynamic Graph on Parent To: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: pd-list@iem.at Date: Sunday, October 3, 2010, 5:55 PM On Thu, 30 Sep 2010, IOhannes m zmoelnig wrote:
On 2010-09-30 13:59, Mathieu Bouchard wrote:
It's not a concept of "this" as brandon wants it
because it's not a
receive-symbol. In iemguts, what is being used is
a number that is the
number of canvases to be climbed up the hierarchy
: so, to get from a
subpatch of a subpatch of an abstraction, to the
parent of the
abstraction, it takes the number 3.
do you mean [sendcanvas 3] would fullfill brandon's
requirements?
I mean [sendcanvas 0] would fulfill them, and with a different argument, it can serve different purposes.
I just cloned it as [gf/canvas_send]. It's in the upcoming GridFlow 9.12.
Though this fulfills brandon's requirements, it still doesn't obsolete [namecanvas]. There are some things you can do with dynamic patching and mouse messages that rely on namecanvas to get click-free audio with user interaction, by cutting a dummy object only from the abstraction that was most recently created. It's not pretty, but it works.
Also, when I revised the help patches I removed the sentence about namecanvas being obsolete since it's an incorrect use of the word.
-Jonathan
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC -----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/04/2010 12:42 AM, Jonathan Wilkes wrote:
Though this fulfills brandon's requirements, it still doesn't obsolete [namecanvas]. There are some things you can do with dynamic patching and mouse messages that rely on namecanvas
how do they rely on properties of [namecanvas] that cannot be done with [sendcanvas]?
fgmasdr IOhannes
PS: and you are aware that your not-pretty tricks won't work if the patch-window is not opened...
--- On Tue, 10/5/10, IOhannes m zmölnig zmoelnig@iem.at wrote:
From: IOhannes m zmölnig zmoelnig@iem.at Subject: Re: [PD] namecanvas obsolete? Why? Re: Dynamic Graph on Parent To: pd-list@iem.at Date: Tuesday, October 5, 2010, 12:10 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/04/2010 12:42 AM, Jonathan Wilkes wrote:
Though this fulfills brandon's requirements, it still
doesn't
obsolete [namecanvas]. There are some things you
can do
with dynamic patching and mouse messages that rely on
namecanvas
how do they rely on properties of [namecanvas] that cannot be done with [sendcanvas]?
Actually, I take that back-- I forgot that I could just use a [s]/[r] pair with the [r] going to the [sendcanvas] object. So yes, as far as I can tell, if [sendcanvas] were an internal object it would obsolete [namecanvas].
fgmasdr IOhannes
PS: and you are aware that your not-pretty tricks won't work if the patch-window is not opened...
Yep. I'm just "vis 1"-ing one patch-window, cutting an object, then "vis 0"-ing it, and I never see the open patch-window.
-Jonathan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyq+bMACgkQkX2Xpv6ydvS5GwCghp7G1mr2ogxtjk/Q2ieN8ETz kd8Ani6I3BZOIVMV9Dt7qEfUStDcD48/ =A5tv -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
brandon zeeb -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Mathieu Bouchard