If you're interested, there was a huge thread about this in February, starting about here:
http://lists.puredata.info/pipermail/pd-list/2009-02/067889.html
It continues, too -- it will look like the thread "dies out," but if you look later in that month there will be many more posts with the same subject.
Matt
yep, sure, it works, but, anyway, I just think it would be easier for some operations if we could use "$0" in messages, that's all...
Thanks
Cheers
Alex
hmm, great, thanks, that is what I wondered, if anyone had bothered to bring this up.
Anyway, from the thread:
"you are violating the 3rd rule of $-expansion: "there is no $0 in message-boxes"."
I can deal around with it... but I just wonder if this third rule could be easily revised/changed. I don't see much of a problem, and it would make some stuff easier. So, here is my plead in favor of this case, I support the cause...
But if you say that it would be a pain in the ass, or argue that such rule must be mantained for some logic reason, I am cool.
I've read something about:
"it would make $0 be even more complicated to understand"
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages. Without an exception at all, it should be easier to get it, as I understand.
And despite all that, as I see, "$0" on messages is just not good for anything. So, completely useless... it is just like putting a Zero...
Sorry for insisting anyway...
Thanks a lot
On Thu, Nov 12, 2009 at 11:25 AM, Matt Barber brbrofsvl@gmail.com wrote:
If you're interested, there was a huge thread about this in February, starting about here:
http://lists.puredata.info/pipermail/pd-list/2009-02/067889.html
It continues, too -- it will look like the thread "dies out," but if you look later in that month there will be many more posts with the same subject.
Matt
yep, sure, it works, but, anyway, I just think it would be easier for
some
operations if we could use "$0" in messages, that's all...
Thanks
Cheers
Alex
Hallo, Alexandre Porres hat gesagt: // Alexandre Porres wrote:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages.
That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different.
Ciao
Frank
On Fri, 13 Nov 2009, Frank Barknecht wrote:
Alexandre Porres hat gesagt: // Alexandre Porres wrote:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages.
That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different.
That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different.
$3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero
it's a special case no matter what.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Fri, 13 Nov 2009, Frank Barknecht wrote:
Alexandre Porres hat gesagt: // Alexandre Porres wrote:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages.
That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different.
That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different.
$3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero
it's a special case no matter what.
Right. Which neatly brings the question back around to "why can't $0 be used in message boxes?" I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.*
Since "1024-foo" (where "1024" represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message?
It probably belongs in the "some things will never change in Pd" category; therefore we must resign ourselves to this discussion re-appearing on a regular basis.
Phil Stone http://www.pkstonemusic.com/pubmusic.html
Am 13.11.09 01:31 schrieb "Phil Stone" unter pkstone@ucdavis.edu:
Mathieu Bouchard wrote:
On Fri, 13 Nov 2009, Frank Barknecht wrote:
Alexandre Porres hat gesagt: // Alexandre Porres wrote:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages.
That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different.
That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different.
$3 stands for ce_argv[2] $2 stands for ce_argv[1] $1 stands for ce_argv[0] $0 stands for ce_dollarzero
it's a special case no matter what.
Right. Which neatly brings the question back around to "why can't $0 be used in message boxes?" I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.*
Since "1024-foo" (where "1024" represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message?
It probably belongs in the "some things will never change in Pd" category; therefore we must resign ourselves to this discussion re-appearing on a regular basis.
$0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. I wouldn't want to have to pay attention to n in $n in order to determine its behaviour. And i also don't support a change that would introduce an inconsistency like that. Why don't people fight with the same effort to make $1 in message boxes be replaced by the first argument of the patch?
Personally, i find it 'unecological' to just not use $0 at all in message boxes. I am haven't checked, but i think this idea must have been brought up already:
Let's make $0 in message boxes be replaced by the selector of the incoming messages. Currently, it is quite cumbersome to type check a pd message and it requires a lot of patching. Using $0 to get the '0th' element of the incoming message would be consistent with the way $-variables are currently used in message boxes and it would be tremendously useful. Just to illustrate the proposed use of $0:
the incoming message: the respective $0 'hallo velo' 'hallo' 'list mein fahrrad' 'list' 'symbol bike' 'symbol' '12 twentyfour' 'list' '12' 'float' 'bang' 'bang' 'bla' 'bla'
If this could be implemented, any future discussion about why $0 in message boxes is not replaced by the canvas identifier would be lapsed.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
This is obviously a loop. All this has been said and proposed before in the thread 1, that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already.
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
It would certainly end the discussions about the special (somehow undefined) state it has now.
roman
Am 13.11.09 10:52 schrieb "Roman Haefeli" unter reduzierer@yahoo.de:
Am 13.11.09 01:31 schrieb "Phil Stone" unter pkstone@ucdavis.edu:
Mathieu Bouchard wrote:
On Fri, 13 Nov 2009, Frank Barknecht wrote:
Alexandre Porres hat gesagt: // Alexandre Porres wrote:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages.
That may be because your students assume, that $1 in a message box is the same as $1 in an object box when in fact it's something different.
That may be because you assume that objectboxes' $0 must have something to do with $1,$2,$3,... when in fact it's something different.
$3 stands for ce_argv[2] $2 stands for ce_argv1 $1 stands for ce_argv[0] $0 stands for ce_dollarzero
it's a special case no matter what.
Right. Which neatly brings the question back around to "why can't $0 be used in message boxes?" I've said this before (to no avail): it is well understood that $0 has no meaning in *messages* -- however, this is not a good reason why $0 can't be used in *message boxes.*
Since "1024-foo" (where "1024" represents the canvas-identifier), *does* have meaning in messages, why must we jump through (admittedly minor, but still quite annoying) hoops just to get that canvas-identifier into a message?
It probably belongs in the "some things will never change in Pd" category; therefore we must resign ourselves to this discussion re-appearing on a regular basis.
$0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list. I wouldn't want to have to pay attention to n in $n in order to determine its behaviour. And i also don't support a change that would introduce an inconsistency like that. Why don't people fight with the same effort to make $1 in message boxes be replaced by the first argument of the patch?
Personally, i find it 'unecological' to just not use $0 at all in message boxes. I am haven't checked, but i think this idea must have been brought up already:
Let's make $0 in message boxes be replaced by the selector of the incoming messages. Currently, it is quite cumbersome to type check a pd message and it requires a lot of patching. Using $0 to get the '0th' element of the incoming message would be consistent with the way $-variables are currently used in message boxes and it would be tremendously useful. Just to illustrate the proposed use of $0:
the incoming message: the respective $0 'hallo velo' 'hallo' 'list mein fahrrad' 'list' 'symbol bike' 'symbol' '12 twentyfour' 'list' '12' 'float' 'bang' 'bang' 'bla' 'bla'
If this could be implemented, any future discussion about why $0 in message boxes is not replaced by the canvas identifier would be lapsed.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already.
Hi Roman,
I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, and it's annoying to more experienced programmers.
I want to address the point you brought up in the first message:
$0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list.
But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2.... in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument repeated over and over as justification for its prohibition in message boxes? I just don't understand this.
If only (as many have said) "$0" had been written as "#0" or something else completely un-encumbered with ideas about what "$" must mean in Pd.
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or "pure", given the unique role that $0 has in *all* cases.
When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months!
Best,
Phil Stone wrote:
I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies,
i agree
and it's annoying to more experienced programmers.
but i can't follow here .-)
But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2.... in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument
actually i do. obviously it would break everything, so i won't say that loud.
repeated over and over as justification for its prohibition in message boxes? I just don't understand this.
If only (as many have said) "$0" had been written as "#0" or something else completely un-encumbered with ideas about what "$" must mean in Pd.
but why "0"? what is #1 to mean then? i always favoured a more bash-like syntax, e.g. "$$" (which is the PID of a process; i think this maps nicely to what $0 currently is)
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
because i want to get the selector of an object-box as well (it's name).
Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or "pure", given the unique role that $0 has in *all* cases.
as explained lengthily months ago, i still don't think that messages should have any notion of the surrounding patch.
When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months!
don't know whether we should. most likely, we will.
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
Phil Stone wrote:
I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies,
i agree
and it's annoying to more experienced programmers.
but i can't follow here .-)
Well, I'm annoyed. :-) But I think I'll get over it.
But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2.... in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument
actually i do. obviously it would break everything, so i won't say that loud.
<snip> as explained lengthily months ago, i still don't think that messages should have any notion of the surrounding patch.
I'd be interested in reading that, though I haven't been able to find the post yet. Do you have a reference?
Currently, the only time I've needed to get $0 into a message is for
dynamic patching. Since this practice is an unloved bastard child of
Pd, it's unlikely I'll get anywhere advocating for making it easier.
Nevertheless, the less-readable patches (as if dynamic patches aren't
obscure enough!) that result from the contortions needed to get $0 into
the message annoy me, and tempt me to write bad, name-clash-ripe dynamic
objects.
Best,
On Fri, 2009-11-13 at 18:08 +0100, IOhannes m zmoelnig wrote:
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
because i want to get the selector of an object-box as well (it's name).
What the hell is the selector of an object box?
Not addressed to you directly, IOhannes: What is so difficult about thinking the canvas identifier as an implicitly given argument to a patch? If seen as that, it is not special at all as it is used in objects. While currently it still has a special status, how it is (not) used in message boxes.
I see, that i am not adding to this discussion anymore. Sorry for that. Nevertheless, i'll fight against any change, that'll add inconsistencies.
Roman
On Fri, 13 Nov 2009, Roman Haefeli wrote:
On Fri, 2009-11-13 at 18:08 +0100, IOhannes m zmoelnig wrote:
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
because i want to get the selector of an object-box as well (it's name).
What the hell is the selector of an object box?
when an objectbox is created, its contents («binbuf») are $-evaluated as when a messagebox receives a message (but commas and semicolons are left untouched), and then the whole contents are sent to &pd_objectmaker as a message. therefore [moses 42] has receiver=&pd_objectmaker, selector=moses, $1=42.
The selector is the creator's name, which is usually the same as the class' name, but not always (because aliases are possible). The difference is mostly only visible in the default names of helpfiles. I often say that the classname is the selector, even though it's not technically true, because it's almost true (a damn lot more than calling it the objectname, anyway).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
While definitely understanding your irritation, the only point of your writing i was able to find is that it would make it 'easier'.
I definitely cannot support the idea of making one special case (that arises a lot, i admit) easier, while disregarding completely the concepts and consistency.
Luckily, i don't have make this decision. However, i still think $0 in message boxes should expand to the selector of the incoming message.
roman
On Fri, 2009-11-13 at 08:54 -0800, Phil Stone wrote:
Roman Haefeli wrote:
This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already.
Hi Roman,
I think the fact that this is an eternally-recurring topic points to just how irritating this one little foible of Pd is -- it's confusing to newbies, and it's annoying to more experienced programmers.
I want to address the point you brought up in the first message:
$0 in messages is only special in the sense, that it has no meaning at all. it wouldn't make it less special to use it as a container for canvas identifier in message boxes. $-variables in objects have a different meaning from $-variables in message boxes, no matter what. I understand, that it would make patching often a lot easier, but conceptually it would be exceptional to make $0 in message-boxes be replaced by the canvas-identifier, while all other $n-variables in message-boxes get replaced by the n-th element of the incoming list.
But $0 is exceptional in *all* cases! Its use in objects has a very different meaning than the use of $1, $2.... in objects. Yet no one calls for eliminating $0 from object boxes -- why is the same argument repeated over and over as justification for its prohibition in message boxes? I just don't understand this.
If only (as many have said) "$0" had been written as "#0" or something else completely un-encumbered with ideas about what "$" must mean in Pd.
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
Well, I think that would make things even worse - further muddying the waters, as it were, by adding yet another meaning to the dollar-sign. I don't see it as any more consistent or "pure", given the unique role that $0 has in *all* cases.
When all is said and done, things in the Pd world will go on as they have, and we won't really suffer because of this one little grain of sand in our shell. But we probably will continue to discuss it every few months!
Best,
Phil http://www.pkstonemusic.com/pubmusic.html
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Roman Haefeli wrote:
While definitely understanding your irritation, the only point of your writing i was able to find is that it would make it 'easier'.
No, it's that the idea of "$0 = special case" is only used when talking about message boxes; $0 is also a special case in object boxes, yet it is accepted there. Thus, I find this argument inconsistent.
I am quite willing to bear the continued burden of coaxing $0 into messages for dynamic patching (I simply have no choice). I would just like to see the reasoning against $0 in message boxes be less specious, and therefore less confusing to the overall issue.
I definitely cannot support the idea of making one special case (that arises a lot, i admit) easier, while disregarding completely the concepts and consistency.
As I said, it's the very *inconsistency* of this argument that bothers me.
--- On Fri, 11/13/09, Roman Haefeli reduzierer@yahoo.de wrote:
From: Roman Haefeli reduzierer@yahoo.de Subject: Re: [PD] Finding "$0" and dealing with it in messages To: "Roman Haefeli" reduzierer@yahoo.de, "Phil Stone" pkstone@ucdavis.edu, "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at Date: Friday, November 13, 2009, 11:21 AM This is obviously a loop. All this has been said and proposed before in the thread [1], that has been posted by alex porres a few posts back. Sorry for not having brought any new perspectives into the discussion, but having just repeated what has been said already.
The only thing i don't really get: Why seems there some agreement, that using $0 to get the selector could be confusing?
It would certainly end the discussions about the special (somehow undefined) state it has now.
You can already use [symbol] to get the selector of an incoming message. I can't think of many patches where I would utilize $0 to get the selector, but I can think of lots of abstractions where treating $0 in msg boxes the same as in object boxes would have been very convenient.
-Jonathan
On Mon, 16 Nov 2009, Jonathan Wilkes wrote:
You can already use [symbol] to get the selector of an incoming message.
It doesn't work for those selectors:
bang symbol list
To handle these cases, you need to also have [route bang symbol list], three messageboxes that say «symbol bang» «symbol symbol» and «symbol list», and three [b] to protect those messageboxes from whatever comes out of [route]. then the else-case of [route] goes to [symbol].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Mon, 11/16/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Finding "$0" and dealing with it in messages To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Roman Haefeli" reduzierer@yahoo.de, "Phil Stone" pkstone@ucdavis.edu, pd-list@iem.at Date: Monday, November 16, 2009, 8:23 PM On Mon, 16 Nov 2009, Jonathan Wilkes wrote:
You can already use [symbol] to get the selector of an
incoming message.
It doesn't work for those selectors:
bang symbol list
Why do you say it doesn't work for list?
To handle these cases, you need to also have [route bang symbol list], three messageboxes that say «symbol bang» «symbol symbol» and «symbol list», and three [b] to protect those messageboxes from whatever comes out of [route]. then the else-case of [route] goes to [symbol].
As far as I can tell you just need [route bang symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content.
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 16 Nov 2009, Jonathan Wilkes wrote:
--- On Mon, 11/16/09, Mathieu Bouchard matju@artengine.ca wrote:
It doesn't work for those selectors: bang symbol list
Why do you say it doesn't work for list?
because it doesn't.
As far as I can tell you just need [route bang symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content.
You are right, two [b] are extraneous. You still need [b] to protect msgbox «symbol list» from [route list].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Mon, 11/16/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Finding "$0" and dealing with it in messages To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Roman Haefeli" reduzierer@yahoo.de, "Phil Stone" pkstone@ucdavis.edu, pd-list@iem.at Date: Monday, November 16, 2009, 8:59 PM On Mon, 16 Nov 2009, Jonathan Wilkes wrote:
--- On Mon, 11/16/09, Mathieu Bouchard matju@artengine.ca
wrote:
It doesn't work for those selectors: bang symbol
list
Why do you say it doesn't work for list?
because it doesn't.
Well, if you send the message "list 7" to [symbol] it will output "symbol list," when, according to all_about_data_types.pd, it ought to output "symbol float." Other than this, are there instances where [symbol] doesn't work correctly with lists?
As far as I can tell you just need [route bang
symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content.
You are right, two [b] are extraneous. You still need [b] to protect msgbox «symbol list» from [route list].
In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element.
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
Well, if you send the message "list 7" to [symbol] it will output "symbol list," when, according to all_about_data_types.pd, it ought to output "symbol float."
Here (Pd version 0.42.4) [symbol], the object box, outputs "symbol list". However [symbol, the graphical atom, shows "float". Probably some artifact of automatic converson going on behind our backs. A third possibility would be to bail out with an error "No message for list/float". I would prefer this behaviour. It's consistent with the behaviour of [float] receiving a "list abc" message.
Regarding all_about_data_types.pd: Personally I wouldn't trust this patch.
Ciao
Frank
On Nov 24, 2009, at 10:01 AM, Frank Barknecht wrote:
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
Well, if you send the message "list 7" to [symbol] it will output "symbol list," when, according to all_about_data_types.pd, it ought
to output "symbol float."Here (Pd version 0.42.4) [symbol], the object box, outputs "symbol
list". However [symbol, the graphical atom, shows "float". Probably some
artifact of automatic converson going on behind our backs. A third possibility
would be to bail out with an error "No message for list/float". I would prefer
this behaviour. It's consistent with the behaviour of [float] receiving a
"list abc" message.Regarding all_about_data_types.pd: Personally I wouldn't trust this
patch.
Its a patch with examples, if you don't trust the examples, then that
seems to mean you don't trust Pd ;)
.hc
kill your television
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Regarding all_about_data_types.pd: Personally I wouldn't trust this
patch.Its a patch with examples, if you don't trust the examples, then that
seems to mean you don't trust Pd ;)
To me the fundamental flaw of the data types patch is that it tries to infer information about Pd's "data types" from the behaviour of selected objects, but doesn't explain the underlying mechanisms.
Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors). IMO an explanation of the mechanisms is imporant to understand, where or why objects behave "strange". all_about_data_types.pd doesn't even use the word "selector" anywhere. Instead it talks about "casting" but doesn't explain what that means (in the patch it means adding a "symbol"-selector to a meta-message). It has several vague sentences in it like: "Many objects cast the data they receive when they output it" or "Some objects do not cast the data". This doesn't make me any smarter.
All in all, I don't think, the patch tells you "All About Data Types". But maybe it just has a misleading name.
Ciao
Frank
Am 25.11.09 09:48 schrieb "Frank Barknecht" unter fbar@footils.org:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Regarding all_about_data_types.pd: Personally I wouldn't trust this patch.
Its a patch with examples, if you don't trust the examples, then that seems to mean you don't trust Pd ;)
To me the fundamental flaw of the data types patch is that it tries to infer information about Pd's "data types" from the behaviour of selected objects, but doesn't explain the underlying mechanisms.
Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors). IMO an explanation of the mechanisms is imporant to understand, where or why objects behave "strange". all_about_data_types.pd doesn't even use the word "selector" anywhere. Instead it talks about "casting" but doesn't explain what that means (in the patch it means adding a "symbol"-selector to a meta-message). It has several vague sentences in it like: "Many objects cast the data they receive when they output it" or "Some objects do not cast the data". This doesn't make me any smarter.
I wonder, what makes one any smarter. It doesn't make you any smarter, when knowing about all the underlying mechanisms and special cases of Pd, it only makes you know more. However, it *would* you make smarter, if you would be able to apply your current experiences on new cases, that you haven't experienced before, for instance: you found, that [route] strips the selector off the message 'list one two' and 'hallo velo', so that you would naturally assume, that [route] would strip off any selector. However, it doesn't, which makes you have to learn every single case separately. Smartness doesn't help here, only diligence. Unfortunately, when it comes to Pd data types, smartness doesn't apply. So we're left with documenting all_(the special cases)_about_data_types(.pd).
If there are things two say about some the of the (special or not) cases, wouldn't it be a good idea to simply add them? Generally i think, that having such a patch isn't a bad idea, since it helps one not to have to find all the cases by experience.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
I wonder, what makes one any smarter. It doesn't make you any smarter, when knowing about all the underlying mechanisms and special cases of Pd, it only makes you know more. However, it *would* you make smarter, if you would be able to apply your current experiences on new cases, that you haven't experienced before, for instance: you found, that [route] strips the selector off the message 'list one two' and 'hallo velo', so that you would naturally assume, that [route] would strip off any selector. However, it doesn't, which makes you have to learn every single case separately.
Of course you have to learn every single object behaviour separately! There's no way around it. [prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be).
But to be able to understand what makes them different, you have to understand at least a little bit about the anatomy of Pd's messages and ideally even how messages with different selectors call different methods of a Pd object. Explaing this makes you smarter. And then being smarter can help with the tedious task of memorizing object behaviours (or knowing when to look them up). Or it will make you add a [list trim] in front of most [route] objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...)
Ciao
Frank
Currently, is there any way to get the selector of a message? The [symbol]/[route] method mentioned earlier in this thread doesn't work for [list( because [route] will convert it to a bang.
In the message [list( the selector is "list," right?
-Jonathan
On Wed, 25 Nov 2009, Jonathan Wilkes wrote:
Currently, is there any way to get the selector of a message? The [symbol]/[route] method mentioned earlier in this thread doesn't work for [list( because [route] will convert it to a bang. In the message [list( the selector is "list," right?
Yes, but it is cast by the pd kernel whenever the list-method is not defined, because then, they inherit the default list-method (pd_defaultlist), which turns every empty list to a bang.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Fri, 12/4/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Finding "$0" and dealing with it in messages To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Friday, December 4, 2009, 1:51 AM On Wed, 25 Nov 2009, Jonathan Wilkes wrote:
Currently, is there any way to get the selector of a
message?
The [symbol]/[route] method mentioned earlier in this
thread doesn't work
for [list( because [route] will convert it to a bang. In the message [list( the selector is "list," right?
Yes, but it is cast by the pd kernel whenever the list-method is not defined, because then, they inherit the default list-method (pd_defaultlist), which turns every empty list to a bang.
Where does the conversion from, say, "list 12" to "float 12" happen in pd? Is it left to each object to convert one-element lists to a symbol/float/pointer?
And getting back to the thread subject: if $0 in msg boxes was changed so that it expands to the selector of the incoming message, what would the following do:
[list 12( | [$0 1 2 3 4(
[list( | [$0 one two three(
-Jonathan
On Thu, 3 Dec 2009, Jonathan Wilkes wrote:
Where does the conversion from, say, "list 12" to "float 12" happen in pd? Is it left to each object to convert one-element lists to a symbol/float/pointer?
pd_defaultlist looks at the content of the list. if the size is 0 and there is a nondefault bangmethod, it is called. if the size is 1 and there is a matching floatmethod, symbolmethod or pointermethod, it is called. otherwise, it will be auto-unpacked and distributed to inlets, unless the object is a «nonpatchable» (that is, it's a DS).
[list 12( | [$0 1 2 3 4(
[list( | [$0 one two three(
The message class defines a method 'list', and because of that, a 'list' selector would naturally stay 'list'.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Am 25.11.09 10:50 schrieb "Frank Barknecht" unter fbar@footils.org:
Of course you have to learn every single object behaviour separately! There's no way around it.
Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(->[symbol] = 'symbol list', whereas [list 45(->[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this. To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both? Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations. Thinking of the the [symbol] vs. [symbol\ and the [route] example (you mention below), one is just left with trying out the different cases and remember them.
[prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be).
We don't know if it is a bug, but it doesn't seem logical in a common sense of the word 'logical'.
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(->[symbol] = 'symbol list', whereas [list 45(->[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this.
Personally I consider this a kind of inconsistency bug.
To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both?
I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in. Or said in another way: You can select what behaviour you want an object to show by prefixing your messages with a certain "selector" - this is where the word "selector" comes from. For example a [delay] object has these behaviour methods on the first inlet:
a) send a bang after the time of its stored delay time b) set the stored delay time to x and send a bang after that time c) cancel any scheduled bangs
You select behaviour a) by sending a "bang" message, you select b) by messages with selector "float" and c) with selector "stop".
On the C-code side, this is handled with messages like delay_bang(), delay_float(), delay_stop() that get called according to the selector. If you write an abstraction, you can mimick the same things with [route float bang stop]. You've all done this already.
What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave "strange" or inconsistent. But these inconsistencies are not caused by the message mechanism behind it, they are caused by the object's author, either deliberatly or not.
Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations.
I hope you're a bit smarter now, but probably you still cannot make predictions. :)
Thinking of the the [symbol] vs. [symbol\ and the [route] example (you mention below), one is just left with trying out the different cases and remember them.
Or thinking about making a bug report/feature wish.
Ciao
Frank
Hi Frank
Thanks a lot for giving me such detailed insight.
Am 26.11.09 09:24 schrieb "Frank Barknecht" unter fbar@footils.org:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(->[symbol] = 'symbol list', whereas [list 45(->[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this.
Personally I consider this a kind of inconsistency bug.
Ok.
To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both?
I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in.
...
What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave "strange" or inconsistent.
Ok, i see. If i understand right, this would also make it possible to deliberately create a message 'list 23' at the outlet, which is probably converted to a 'float 23' by the next object's outlet (_if_ this next object's inlet knows what to do with the selector 'list'). Unfortunately, knowing this doesn't make me understand what happens here - for instance:
[list 23( | [print]
which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages?
Is there a way to know what goes through a connection wire?
Also interesting cases to consider:
[list velo( -> 'symbol velo' [float 12 34( -> '12'
But these inconsistencies are not caused by the message mechanism behind it, they are caused by the object's author, either deliberatly or not.
I see. Let me pick an example, which to me is not quite clear, which of the involved object classes should be considered buggy:
[foo 56(
|
[route foo]
|
[*~ ]
This raises an error: inlet: expected 'signal' but got 'list' Is it [route]'s fault not to spit out a message with 'float' selector, since obviously the message contains only a single element? Or is [*~ ] supposed to accept single-element-lists as well and raise only an error, when the single-element-list contains a symbol, but not a float?
Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations.
I hope you're a bit smarter now, but probably you still cannot make predictions. :)
Hmm.. i guess, you're right...
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo Roman, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
Am 26.11.09 09:24 schrieb "Frank Barknecht" unter fbar@footils.org:
To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both?
I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in.
...
What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave "strange" or inconsistent.
Ok, i see. If i understand right, this would also make it possible to deliberately create a message 'list 23' at the outlet, which is probably converted to a 'float 23' by the next object's outlet (_if_ this next object's inlet knows what to do with the selector 'list').
Ok, here you mention a different thing, which is the automatic conversion of "special" messages, i.e. "list 23" is just a "float 23" which is the same as "23", or "list" being the same as "bang".
I must admit, that I don't really know where and how this is happening in Pd. As you wrote, sometimes this conversion isn't working. A good example is the right (or non-leftmost) inlet of the signal math objects: If they are created so that normally both signals and floats can be sent into them, they only like "real" floats, that is messages with selector "float" or numbers. They won't accept messages coming out ot a [t a] either:
[0
|
[t a a]
| |
[*~ ]
This gives "error: inlet: expected 'signal' but got 'list'" on the right inlet. But if you disconnect the right inlet, the same "anything-float" is accepted on the first inlet.
Maybe IOhannes can explain the background? IIRC he wrote a patch that fixes this so that [t a] works for non-leftmost signal inlets as well.
Unfortunately, knowing this doesn't make me understand what happens here - for instance:
[list 23( | [print]
which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages?
Apart from the fact that [print] is a very bad helper in this case, I don't know where and how "list 23" is made to be 23, see above. :(
Ciao
Frank
Am 26.11.09 12:13 schrieb "Frank Barknecht" unter fbar@footils.org:
Unfortunately, knowing this doesn't make me understand what happens here - for instance:
[list 23( | [print]
which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages?
Apart from the fact that [print] is a very bad helper in this case, I don't know where and how "list 23" is made to be 23, see above. :(
I found another interesting example:
[float velo(
Clicking on this message box raises the following error:
error: Bad arguments for message 'float' to object 'messresponder'
Obviously, the message box already does some parsing and tries to generate a 'coherent' pd message, which fails in this case.
btw: funny milleresque name: 'messresponder' :-)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 25 Nov 2009, Roman Haefeli wrote:
To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both?
It is always at the inlet. You will not figure this out by using [print] or [route], which are both designed to hide the inconsistency under the carpet. They both contain the combination of if-statements required to mask the problem. Basically each of those classes contains a replica of much of pd_defaultlist, only in a way that doesn't look like copy+paste.
[prepend] in Cyclone is different from [list prepend], and that's by design, not a bug (as symbol-selector handling in [route] might be).
We don't know if it is a bug, but it doesn't seem logical in a common sense of the word 'logical'.
«logical» thus means «something that follows from a set of rules (instead of just being a rule of its own)» instead of the other possible definitions of «something that follows the rules instead of not following them» and «something that was found using the rules instead of being found by other means»... (I didn't look at dictionary for this, I thought about what are the uses of the word that I do encounter in practice.)
But because the whole set of rules hasn't been defined or agreed upon, we don't know whether anything is logical or not, because logic always starts from a set of basic rules (which can't be deduced from any other rules... at least not literally).
Actually, we can know, as this is written in Pd's source code (and Dd's source code). It's just that the source has to be read... (well, if someone can find Martin Peach's internals doc, I can't find it atm, so I can't tell whether it documents this or not).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hello, Can [sigmund~] do everything [fiddle~] can do (or do it better)?
BTW: I'm finding that to use [sigmund~] with tables, the "-t flag" is unnecessary-- just remove it in the example in the subpatch and you get the same results. Not sure if that's a bug or not, but it makes me wonder: what's the purpose of having the -t flag?
Thanks, Jonathan
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
Can [sigmund~] do everything [fiddle~] can do (or do it better)?
I leave the first part of the question as a task to the reader of both help files. About the second part: In my tests, [sigmund~] indeed did it better.
Ciao
Frank
--- On Mon, 12/7/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] [sigmund~] and [fiddle~] To: pd-list@iem.at Date: Monday, December 7, 2009, 10:04 AM Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
Can [sigmund~] do everything [fiddle~] can do (or do
it better)?
I leave the first part of the question as a task to the reader of both help files.
I don't understand: Does this mean you haven't read them? That you have and it's obvious? That you have and it isn't?
Unless I'm overlooking something, neither help patch mentions the other object. Obviously [sigmund~] has a lot more "goodies" than [fiddle~], but without spending a long span of time studying each object in depth, it's unclear whether some functions of [fiddle~] were left out of [sigmund~] or subsumed under one of its new features.
If anyone has some experience using both objects, it would be nice to add a sentence to [sigmund~]'s help patch clarifying its relationship to [fiddle~] (and vice versa).
Thanks, Jonathan
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
--- On Mon, 12/7/09, Frank Barknecht fbar@footils.org wrote:
Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
Can [sigmund~] do everything [fiddle~] can do (or do
it better)?
I leave the first part of the question as a task to the reader of both help files.
I don't understand: Does this mean you haven't read them? That you have and it's obvious? That you have and it isn't?
I'm sorry, my attempt to be funny seemed to have failed horribly.
Both sigmund~ and fiddle~ do pitch tracking and sinusoidal analysis, i.e. track partials in a signal. Where fiddle~ uses a fixed set of outlets to report various pitch info, sigmund~ reconfigures its outlets according to arguments. Both fiddle~ and sigmund~ can give similar info, in fact it's almost the same. I won't repeat these here, for this indeed check the help files. sigmund~ doesn't have an explicit attack outlet, instead you use the more "musical" "note" outlet, which combines pitch and attack info. The various internal configuration settings of both objects are practically the same as well, some are reorganized a bit( i.e. amp-range is gone in sigmund~ which instead offers minpower and growth)
Unless I'm overlooking something, neither help patch mentions the other object. Obviously [sigmund~] has a lot more "goodies" than [fiddle~], but without spending a long span of time studying each object in depth, it's unclear whether some functions of [fiddle~] were left out of [sigmund~] or subsumed under one of its new features.
Obviously it's not that obvious. :) (I'm trying to be funny here again!) As I see it sigmund~ doesn't have that many new goodies (except table analysis). It seems to be more like a cosmetic rewrite to make it easier to use than fiddle~. The number of outlets has been reduced and their meaning is clearer IMO.
But under the hood I think it uses a better algorithm. In my experiments it reports pitch faster and more reliable and stable than fiddle~. So if you can use sigmund~ I would recommend it over fiddle~ as a replacement.
Ciao
Frank
But under the hood I think it uses a better algorithm. In my experiments it reports pitch faster and more reliable and stable than fiddle~. So if you can use sigmund~ I would recommend it over fiddle~ as a replacement.
Back in the LAC 2008 in Cologne, I asked Miller that very question: what is the difference between fiddle~ and sigmund~. He said sigmund~ was the best pitch tracker he had programmed so far. So I guess fiddle is still alive just for compatibility reasons.
alabala
I only have little experience, but from what I've seen so far is that pitch detection with sigmund~ is faster than fiddle~.
On the other hand I found the level setting 'minpower' not working or at least nor responsive to changes that I tried out. I do not have experimented with the corresponding settings in fiddle~.
Jurgen
On Dec 8, 2009, at 6:10 PM, ypatios wrote:
But under the hood I think it uses a better algorithm. In my experiments it reports pitch faster and more reliable and stable than fiddle~. So if you can use sigmund~ I would recommend it over fiddle~ as a replacement.
Back in the LAC 2008 in Cologne, I asked Miller that very question: what is the difference between fiddle~ and sigmund~. He said sigmund~ was the best pitch tracker he had programmed so far. So I guess fiddle is still alive just for compatibility reasons.
alabala
-- ypatios _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 25, 2009, at 1:50 AM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
I wonder, what makes one any smarter. It doesn't make you any
smarter, when knowing about all the underlying mechanisms and special cases of
Pd, it only makes you know more. However, it *would* you make smarter, if you
would be able to apply your current experiences on new cases, that you haven't experienced before, for instance: you found, that [route] strips the selector off the message 'list one two' and 'hallo velo', so that
you would naturally assume, that [route] would strip off any selector.
However, it doesn't, which makes you have to learn every single case separately.Of course you have to learn every single object behaviour
separately! There's no way around it. [prepend] in Cyclone is different from [list
prepend], and that's by design, not a bug (as symbol-selector handling in [route]
might be).But to be able to understand what makes them different, you have to
understand at least a little bit about the anatomy of Pd's messages and ideally
even how messages with different selectors call different methods of a Pd
object. Explaing this makes you smarter. And then being smarter can help
with the tedious task of memorizing object behaviours (or knowing when to
look them up). Or it will make you add a [list trim] in front of most [route]
objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...)
Add something about [list trim]. :) all_about_data_types is older
than than the list object.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Or it will make you add a [list trim] in front of most [route]
objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim] inside ...)Add something about [list trim]. :) all_about_data_types is older than than the list object.
I have written a bit about Pd's messages on puredata.info, feel free to quote as much as you like. I'm not the right person to fix pd-extended docs. I can't even create all objects in that patch and bug 2026128 is still open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :)
Ciao
Frank
On Nov 29, 2009, at 3:26 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Or it will make you add a [list trim] in front of most [route] objects. (Btw.: all_about_data_types.pd doesn't have a single [list trim]
inside ...)Add something about [list trim]. :) all_about_data_types is older
than than the list object.I have written a bit about Pd's messages on puredata.info, feel free
to quote as much as you like. I'm not the right person to fix pd-extended
docs. I can't even create all objects in that patch and bug 2026128 is still
open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :)
The PDDP docs predate pd-extended. The PDDP could easily be
distributed or used by anyone. That patch is related to PDDP. But
yes, Pd-extended does include the PDDP docs. What's the point of
writing all this email about the topic if it doesn't actually end up
in something useful? Few people read the archives...
I don't understand this anti-Pd-extended puritanism. Does
distributing docs or code in Pd-extended somehow taint it with evil?
I think the PDDP docs are mostly really good. Most of that work was
done by Dave Sabine. Why wouldn't we use it and keep it up to date?
.hc
Mistrust authority - promote decentralization. - the hacker ethic
On Thu, 3 Dec 2009, Hans-Christoph Steiner wrote:
I don't understand this anti-Pd-extended puritanism.
You don't need to understand it, you just need to avoid it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 29, 2009, at 3:26 AM, Frank Barknecht wrote:
I have written a bit about Pd's messages on puredata.info, feel free to quote as much as you like. I'm not the right person to fix pd-extended docs. I can't even create all objects in that patch and bug 2026128 is still open, which indicates, that we believe different things about data types and messages. I don't want to get into that discussion again. :)
The PDDP docs predate pd-extended. The PDDP could easily be distributed or used by anyone. That patch is related to PDDP. But yes, Pd-extended does include the PDDP docs. What's the point of writing all this email about the topic if it doesn't actually end up in something useful? Few people read the archives...
I don't understand this anti-Pd-extended puritanism. Does distributing docs or code in Pd-extended somehow taint it with evil? I think the PDDP docs are mostly really good. Most of that work was done by Dave Sabine.
Why wouldn't we use it and keep it up to date?
Hey, all I said is that *I* am not the right person to do that.
Ciao
Frank
--- On Sat, 12/5/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] Finding "$0" and dealing with it in messages To: pd-list@iem.at Date: Saturday, December 5, 2009, 1:09 PM Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 29, 2009, at 3:26 AM, Frank Barknecht wrote:
I have written a bit about Pd's messages on
puredata.info, feel free to
quote as much as you like. I'm not the right
person to fix pd-extended docs.
I can't even create all objects in that patch and
bug 2026128 is still
open, which indicates, that we believe different
things about data types and
messages. I don't want to get into that discussion
again. :)
The PDDP docs predate pd-extended. The PDDP
could easily be distributed
or used by anyone. That patch is related to
PDDP. But yes, Pd-extended
does include the PDDP docs. What's the point of
writing all this email
about the topic if it doesn't actually end up in
something useful? Few
people read the archives...
I don't understand this anti-Pd-extended
puritanism. Does distributing
docs or code in Pd-extended somehow taint it with
evil? I think the PDDP
docs are mostly really good. Most of that work
was done by Dave Sabine.
Why wouldn't we use it and keep it up to date?
Hey, all I said is that *I* am not the right person to do that.
If that's all you had said, I doubt anyone would have replied with anything other than "ok."
And now I'm curious: why can't you create all the objects in that patch? If some of those objects don't create in pd-ext on win/macos/ linux, at the very least the patch should be changed so that they are removed (or replaced with ascii art).
But if it's that you just prefer using pd-vanilla and don't want to download/install pd-ext, why not just say that?
-Jonathan
Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
--- On Sat, 12/5/09, Frank Barknecht fbar@footils.org wrote:
Hey, all I said is that *I* am not the right person to do that.
If that's all you had said, I doubt anyone would have replied with anything other than "ok."
And now I'm curious: why can't you create all the objects in that patch? If some of those objects don't create in pd-ext on win/macos/ linux, at the very least the patch should be changed so that they are removed (or replaced with ascii art).
But if it's that you just prefer using pd-vanilla and don't want to download/install pd-ext, why not just say that?
Some history:
I was involved in early PDDP discussions (around 2005) as well, so PDDP isn't new to me. I dropped out of PDDP for various reasons after a while. Besides the endless discussion about template layout etc. another reason for my retreat was, that the help system started to require certain externals (pddp_link). I believe, a general purpose help file template should not require objects not available in all major Pd distributions. Help files should be accessible to everyone. I wasn't alone with this view, see: http://puredata.info/dev/pddp/2005-11-22-pddp_meeting.txt for example. Some other PDDP contributors didn't have a problem with that. I can accept that, but obviously I had to stop contributing at that point. Some other early participants also dropped out, some for similar reasons IIRC.
While I'm surely guilty of some anti-Pd-extended puritanism, my retreat from PDDP didn't have anything to do with it. It has a different story.
(I'm sorry for saying "pd-extended docs" in my previous mail, it should have been "PDDP docs".)
Ciao
Frank
On Sun, 6 Dec 2009, Frank Barknecht wrote:
I was involved in early PDDP discussions (around 2005) as well, so PDDP isn't new to me. I dropped out of PDDP for various reasons after a while. Besides the endless discussion about template layout etc. another reason for my retreat was, that the help system started to require certain externals (pddp_link).
I was never really involved in PDDP discussions because it is definitely not right that documentation writers would have to mess endlessly with [cnv] sizes and pixel-precise positioning all of the time. Standards that require more work aren't as good as standards that require less work. Following the PDDP standard requires more work than the traditional way of making help files. Following the GFDP requires less work than the PDDP, but that's not all, it also requires less work than making help patches the traditional way! Especially for people who aren't quite happy with approximate layouts.
I can accept that, but obviously I had to stop contributing at that point. Some other early participants also dropped out, some for similar reasons IIRC.
How many of those PDDP contributors would have dropped out at the point that they would have had to use the template that they designed? Obviously it's fun getting together on the chatline and talk about each person's favourite colours and each person's favourite help-patch width, but living with the consequences of those decisions is something different. That's why in the end not much was done after the decisions were made. (If there's any hidden stash of PDDP docs that *do* follow the PDDP standard, I'd like to know.)
While I'm surely guilty of some anti-Pd-extended puritanism, my retreat from PDDP didn't have anything to do with it. It has a different story.
Regardless of stated theoretical differences, there's not much that separates anti-extended, pro-portability-across-distribs, and pro-vanilla. Why would the distinction matter?
I believe, a general purpose help file template should not require objects not available in all major Pd distributions.
This is a contorted way to say that you only want vanilla.
In any case, GFDP uses a lot of abstractions, which use a lot of externals, and those externals are required for automatic-layout. (GFDP doesn't use [pddp-link] or any equivalent of it so far). If you acknowledged automatic-layout to be an essential feature, then you'd figure out a way to incorporate it that clashes as little as possible with your beliefs. Whereas if you start from your existing beliefs, then you don't even have to ask yourself whether automatic-layout is a good idea.
In October, I rewrote the GridFlow manual. That's 165 help files as of now (actually it should be about 200 help files to be complete). It was enjoyable. GFDP made it fun to write docs, and that's how I got myself to do it the best I could. I wouldn't have had the same level of fun have enjoyed it if I hadn't had the GFDP framework. If I had had to "use" the PDDP template (that is, reimplement it by hand in every !@#$ help file) it would have taken forever, and I wouldn't have gone back nearly as often to add additional notes and rephrase what I had written, thinking «I will have to readjust the [cnv]s one more time if I change ANY text in here.»
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Dec 6, 2009, at 1:40 PM, Mathieu Bouchard wrote:
On Sun, 6 Dec 2009, Frank Barknecht wrote:
I was involved in early PDDP discussions (around 2005) as well, so
PDDP isn't new to me. I dropped out of PDDP for various reasons
after a while. Besides the endless discussion about template layout
etc. another reason for my retreat was, that the help system
started to require certain externals (pddp_link).I was never really involved in PDDP discussions because it is
definitely not right that documentation writers would have to mess
endlessly with [cnv] sizes and pixel-precise positioning all of the
time. Standards that require more work aren't as good as standards
that require less work. Following the PDDP standard requires more
work than the traditional way of making help files. Following the
GFDP requires less work than the PDDP, but that's not all, it also
requires less work than making help patches the traditional way!
Especially for people who aren't quite happy with approximate layouts.
I think we had some useful discussions in PDDP, but not much work came
out of it. It got too bureaucratic. I think the 'official' PDDP
template is a place to start from. I've used a simplified version for
help patches in my 'apple' library, for example.
I think people should learn from PDDP, but not we just need more and
better docs, so people should make them based on the knowledge from
PDDP. Then thru real world use, we can figure out what works best.
.hc
I can accept that, but obviously I had to stop contributing at that
point. Some other early participants also dropped out, some for
similar reasons IIRC.How many of those PDDP contributors would have dropped out at the
point that they would have had to use the template that they
designed? Obviously it's fun getting together on the chatline and
talk about each person's favourite colours and each person's
favourite help-patch width, but living with the consequences of
those decisions is something different. That's why in the end not
much was done after the decisions were made. (If there's any hidden
stash of PDDP docs that *do* follow the PDDP standard, I'd like to
know.)While I'm surely guilty of some anti-Pd-extended puritanism, my
retreat from PDDP didn't have anything to do with it. It has a different story.Regardless of stated theoretical differences, there's not much that
separates anti-extended, pro-portability-across-distribs, and pro- vanilla. Why would the distinction matter?I believe, a general purpose help file template should not require
objects not available in all major Pd distributions.This is a contorted way to say that you only want vanilla.
In any case, GFDP uses a lot of abstractions, which use a lot of
externals, and those externals are required for automatic-layout.
(GFDP doesn't use [pddp-link] or any equivalent of it so far). If
you acknowledged automatic-layout to be an essential feature, then
you'd figure out a way to incorporate it that clashes as little as
possible with your beliefs. Whereas if you start from your existing
beliefs, then you don't even have to ask yourself whether automatic- layout is a good idea.In October, I rewrote the GridFlow manual. That's 165 help files as
of now (actually it should be about 200 help files to be complete).
It was enjoyable. GFDP made it fun to write docs, and that's how I
got myself to do it the best I could. I wouldn't have had the same
level of fun have enjoyed it if I hadn't had the GFDP framework. If
I had had to "use" the PDDP template (that is, reimplement it by
hand in every !@#$ help file) it would have taken forever, and I
wouldn't have gone back nearly as often to add additional notes and
rephrase what I had written, thinking «I will have to readjust the
[cnv]s one more time if I change ANY text in here.»_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone:
+1.514.383.3801_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Sun, 6 Dec 2009, Hans-Christoph Steiner wrote:
I think people should learn from PDDP, but not we just need more and better docs, so people should make them based on the knowledge from PDDP. Then thru real world use, we can figure out what works best.
GFDP was born when trying to use a PDDP template. I tried real world use and I figured out what works best, and it made me make the GFDP template. I wouldn't mind calling my stuff PDDP 2.0 if that makes anyone understand what's going on with that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Sun, 12/6/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] PDDP (was: Finding "$0" and dealing with it in messages) To: "Hans-Christoph Steiner" hans@at.or.at Cc: pd-list@iem.at Date: Sunday, December 6, 2009, 8:08 PM On Sun, 6 Dec 2009, Hans-Christoph Steiner wrote:
I think people should learn from PDDP, but not we just
need more and better docs, so people should make them based on the knowledge from PDDP. Then thru real world use, we can figure out what works best.
GFDP was born when trying to use a PDDP template. I tried real world use and I figured out what works best, and it made me make the GFDP template. I wouldn't mind calling my stuff PDDP 2.0 if that makes anyone understand what's going on with that.
Could you post an example help patch? I downloaded gridflow to check out how your help patches work but I'm on windows so I just get a bunch of broken objects.
-Jonathan
On Sun, 6 Dec 2009, Jonathan Wilkes wrote:
Could you post an example help patch? I downloaded gridflow to check out how your help patches work but I'm on windows so I just get a bunch of broken objects.
Screenshots of all the helpfiles are available at http://gridflow.ca/help/ but this is 0.9.6 (and the new helpfiles are already a bit different). note that those shots are truncated when they are too long (higher than my screen). I didn't code an automated screenshot stitcher yet (and there's no way I'm gonna do this manually).
Some helpfiles that best illustrate GFDP (among those that fit in a screenshot): http://gridflow.ca/help/%23mouse-help.png http://gridflow.ca/help/%23labelling-help.png http://gridflow.ca/help/range-help.png http://gridflow.ca/help/receives-help.png
But really, to appreciate GFDP you have to know that every component is an abstraction instance (except comments), that there are invisible patchcords so that comments have owners, and then there is an automatic positioning system:
http://gridflow.ca/gallery/doc_anim.mov
but this video doesn't demonstrate much of it. Here's a screenshot of range-help.pd when in edit mode:
http://gridflow.ca/gallery/%23range-help-edit.png
patchcords that aren't used for sending messages are dashed and painted orange. The dashed boxes aren't usually there. They can be turned on by editing two abstractions (one for comments and one for non-comments). What you see in this screenshot is by editing only one abstraction; in the video, the other abstraction has been edited. Note that some buttons are visible only when in edit-mode. Note that moving a [doc_m] moves the attached comment around, but moving the comment around has no effect (or may reorder comments if there are several of them). Writing more text in a comment automatically moves all following [doc_m] downwards and so on including higher-level section headings ([doc_oo], [doc_o], etc)
There's more to it. I guess someone with a faster computer than mine could make a video of all the features.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Mon, 12/7/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] PDDP (was: Finding "$0" and dealing with it in messages) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, pd-list@iem.at Date: Monday, December 7, 2009, 2:37 AM On Sun, 6 Dec 2009, Jonathan Wilkes wrote:
Could you post an example help patch? I
downloaded gridflow to check out how your help patches work but I'm on windows so I just get a bunch of broken objects.
Screenshots of all the helpfiles are available at http://gridflow.ca/help/ but this is 0.9.6 (and the new helpfiles are already a bit different). note that those shots are truncated when they are too long (higher than my screen). I didn't code an automated screenshot stitcher yet (and there's no way I'm gonna do this manually).
Some helpfiles that best illustrate GFDP (among those that fit in a screenshot): http://gridflow.ca/help/%23mouse-help.png http://gridflow.ca/help/%23labelling-help.png http://gridflow.ca/help/range-help.png http://gridflow.ca/help/receives-help.png
But really, to appreciate GFDP you have to know that every component is an abstraction instance (except comments), that there are invisible patchcords so that comments have owners, and then there is an automatic positioning system:
http://gridflow.ca/gallery/doc_anim.mov
but this video doesn't demonstrate much of it. Here's a screenshot of range-help.pd when in edit mode:
http://gridflow.ca/gallery/%23range-help-edit.png
patchcords that aren't used for sending messages are dashed and painted orange. The dashed boxes aren't usually there. They can be turned on by editing two abstractions (one for comments and one for non-comments). What you see in this screenshot is by editing only one abstraction; in the video, the other abstraction has been edited. Note that some buttons are visible only when in edit-mode. Note that moving a [doc_m] moves the attached comment around, but moving the comment around has no effect (or may reorder comments if there are several of them). Writing more text in a comment automatically moves all following [doc_m] downwards and so on including higher-level section headings ([doc_oo], [doc_o], etc)
There's more to it. I guess someone with a faster computer than mine could make a video of all the features.
That's some cool stuff. What are the externals that are being used (esp. to hide patch cords and move the abstractions into place? Are the pngs/movs in dd or pd-ext?
-Jonathan
On Sun, 6 Dec 2009, Jonathan Wilkes wrote:
That's some cool stuff. What are the externals that are being used (esp. to hide patch cords and move the abstractions into place?
[gf/lol] has 4 methods: wire_dotted, wire_hide, box_dotted, box_align. Those are used by [doc_m] to move comments into place, and by [doc_also] to put «See Also» objects into place. Loading GridFlow also modifies the running Vanilla or Extended so that comments have an inlet and so that this inlet is hidden.
For moving the abstractions into place, however, [gf/canvas_getpos] and [gf/canvas_setpos] are used. If the patch gets any bigger than the patch window, [gf/canvas_hehehe] is used to auto-expand the window. [gf/canvas_hohoho] is used to draw dashed bounding-boxes.
Other new externals include [gf/canvas_count] and [gf/canvas_loadbang] for dynamic patching. [gf/canvas_xid] is used for automating screenshots. [gf/canvas_edit_mode] reports the edit state, [gf/canvas_setgop] allows an abstraction to change its own GOP settings, [gf/canvas_filename] allows a patch to know its own filename, and [gf/canvas_dollarzero] allows a patch to know the $0 of any of its parents («ancestors»). [gf/string_<] compares strings (to auto-sort [doc_m] elements), [gf/string_replace] is used a few times, and I don't recall what I used [gf/getpid] for (but it gets the process ID).
Are the pngs/movs in dd or pd-ext?
Still all pd-ext, simply because that's what people are going to use at the winter Pd workshop at Vidéographe. This new stuff doesn't work in dd, which will need an entirely different set of hacks anyway. Work on dd is postponed until the workshop is ready...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Dec 7, 2009, at 1:51 PM, Mathieu Bouchard wrote:
On Sun, 6 Dec 2009, Jonathan Wilkes wrote:
That's some cool stuff. What are the externals that are being used
(esp. to hide patch cords and move the abstractions into place?[gf/lol] has 4 methods: wire_dotted, wire_hide, box_dotted,
box_align. Those are used by [doc_m] to move comments into place,
and by [doc_also] to put «See Also» objects into place. Loading
GridFlow also modifies the running Vanilla or Extended so that
comments have an inlet and so that this inlet is hidden.For moving the abstractions into place, however, [gf/canvas_getpos]
and [gf/canvas_setpos] are used. If the patch gets any bigger than
the patch window, [gf/canvas_hehehe] is used to auto-expand the
window. [gf/canvas_hohoho] is used to draw dashed bounding-boxes.Other new externals include [gf/canvas_count] and [gf/ canvas_loadbang] for dynamic patching. [gf/canvas_xid] is used for
automating screenshots. [gf/canvas_edit_mode] reports the edit
state, [gf/canvas_setgop] allows an abstraction to change its own
GOP settings, [gf/canvas_filename] allows a patch to know its own
filename, and [gf/canvas_dollarzero] allows a patch to know the $0
of any of its parents («ancestors»). [gf/string_<] compares strings
(to auto-sort [doc_m] elements), [gf/string_replace] is used a few
times, and I don't recall what I used [gf/getpid] for (but it gets
the process ID).Are the pngs/movs in dd or pd-ext?
Still all pd-ext, simply because that's what people are going to use
at the winter Pd workshop at Vidéographe. This new stuff doesn't
work in dd, which will need an entirely different set of hacks
anyway. Work on dd is postponed until the workshop is ready...
It seems to me that this template is really graphically heavy and
there isn't much text. While the automation tricks are impressive, I
think that we are better off with a simple manual template with just
enough graphical elements to make things clear, no more. Here's an
example of my take on the PDDP template:
.hc
All information should be free. - the hacker ethic
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sun, 6 Dec 2009, Frank Barknecht wrote:
I believe, a general purpose help file template should not require
objects not available in all major Pd distributions.This is a contorted way to say that you only want vanilla.
I am using externals a lot, too. I just don't think they should be part of a general help file template. I think, the help files inside of Pd-vanilla can and should be improved as well. By adding dependencies outside of Pd-vanilla to a template, it cannot be used inside of vanilla anymore. To me this indeed is important.
Ciao
Frank
--- On Sun, 12/6/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] Finding "$0" and dealing with it in messages To: pd-list@iem.at Date: Sunday, December 6, 2009, 12:04 PM Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
--- On Sat, 12/5/09, Frank Barknecht fbar@footils.org
wrote:
Hey, all I said is that *I* am not the right
person to do
that.
If that's all you had said, I doubt anyone would have
replied with
anything other than "ok."
And now I'm curious: why can't you create all the
objects in that
patch? If some of those objects don't create in
pd-ext on win/macos/
linux, at the very least the patch should be changed
so that they are
removed (or replaced with ascii art).
But if it's that you just prefer using pd-vanilla and
don't want to
download/install pd-ext, why not just say that?
Some history:
I was involved in early PDDP discussions (around 2005) as well, so PDDP isn't new to me. I dropped out of PDDP for various reasons after a while. Besides the endless discussion about template layout etc. another reason for my retreat was, that the help system started to require certain externals (pddp_link). I believe, a general purpose help file template should not require objects not available in all major Pd distributions. Help files should be accessible to everyone. I wasn't alone with this view, see: http://puredata.info/dev/pddp/2005-11-22-pddp_meeting.txt for example. Some other PDDP contributors didn't have a problem with that. I can accept that, but obviously I had to stop contributing at that point. Some other early participants also dropped out, some for similar reasons IIRC.
While I'm surely guilty of some anti-Pd-extended puritanism, my retreat from PDDP didn't have anything to do with it. It has a different story.
(I'm sorry for saying "pd-extended docs" in my previous mail, it should have been "PDDP docs".)
Thanks, that clarifies some things.
So if [pddp_link] is removed, and external objects are given as comments in ascii art, would you have any other issues with pddp? (I don't see template layout as a problem because I've been revising all the reference files to conform to one standard, and I can't imagine someone objecting to using them because they don't like the colors or whatever. But the template looks pretty much like the one for [float] in pd-ext.)
[pddp-link] is currently used for pdpedia links, and links to tutorials and other pddp docs. Currently [pddp-link] throws an ugly error msg in windows, although after you close the error message window the link works. I've been spot checking the links from help files to pdpedia, and of 200 help patches roughly 0% of the pdpedia links add anything to what's already in the help patch. If I remove those links then it's just a matter of converting all the "More info" links to comments and voila, no more [pddp-link].
At some point, it would be nice to have either [pddp-link] in all distributions, or have the ability to links within pd comments (actually that would be much more useful in my opinion).
-Jonathan
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 25 Nov 2009, Roman Haefeli wrote:
However, it doesn't, which makes you have to learn every single case separately. Smartness doesn't help here, only diligence. Unfortunately, when it comes to Pd data types, smartness doesn't apply. So we're left with documenting all_(the special cases)_about_data_types(.pd).
The only way to cover everything is to read all of the source code of pd. Every exception that is really an exception will have its own piece of code. Consistent cases that have their own piece of code just slow you down in reading that source code. This is why I took a lot of steps to separate difference and repetition in the pd source code, by using various means such as overloading, macros, meta-macros, abstracting out more functions, and formatting code so that it looks like a table. Eventually, stripping out all the redundantly repetitive mechanics that you can deduce from whatever else, you are left staring at the pure intent behind it all. I didn't reach that point and seldom it is reached by anyone, but the closer you get, the more transparent it becomes.
If there are things two say about some the of the (special or not) cases, wouldn't it be a good idea to simply add them? Generally i think, that having such a patch isn't a bad idea, since it helps one not to have to find all the cases by experience.
Black-box reverse-engineering is the best when you have no other option. Otherwise, do peek under the hood and the source code will tell you everything you want to know. It's probably shorter to learn enough C/C++ and then read pd or dd, than to figure out by yourself all imaginable ways to poke pd's components so that every detail of their behaviour comes out!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Nov 25, 2009, at 12:48 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Regarding all_about_data_types.pd: Personally I wouldn't trust this patch.
Its a patch with examples, if you don't trust the examples, then that seems to mean you don't trust Pd ;)
To me the fundamental flaw of the data types patch is that it tries
to infer information about Pd's "data types" from the behaviour of selected
objects, but doesn't explain the underlying mechanisms.Single objects unfortunatly often behave inconsistently or not as
one maybe would expect (e.g. [route list symbol] strips list- but not symbol- selectors). IMO an explanation of the mechanisms is imporant to understand,
where or why objects behave "strange". all_about_data_types.pd doesn't even use
the word "selector" anywhere. Instead it talks about "casting" but doesn't
explain what that means (in the patch it means adding a "symbol"-selector to a
meta-message). It has several vague sentences in it like: "Many objects cast the
data they receive when they output it" or "Some objects do not cast the
data". This doesn't make me any smarter.All in all, I don't think, the patch tells you "All About Data
Types". But maybe it just has a misleading name.
It should be all about data types, but it doesn't doesn't cover
everything. Please add to it, its in SVN in doc/pddp. Those patches
are there to be improved!
.hc
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Wed, 25 Nov 2009, Frank Barknecht wrote:
Single objects unfortunatly often behave inconsistently or not as one maybe would expect (e.g. [route list symbol] strips list- but not symbol-selectors).
[route] is quite disappointing. I already made [route2] which doesn't modify any message, and I'm gonna make [route3] which outputs "list $1...$n" on any non-last outlet in a consistent manner (and without the weird quirks that happen when you try using [route] for that purpose).
To one who believes that abstractions and externals should have a Pd API that is as similar to each other, [route3] should be obvious: it would correspond more closely to class_addmethod.
all_about_data_types.pd doesn't even use the word "selector" anywhere.
The pd 0.42 source code has the word "selector" once. This word was introduced there in 0.39. On pd-list, there have been occasional uses of the word 'selector' quite early. There's one early mention of 'selector' (by none other than Miller) as early as 1998, but that seems to be an outlier. After that you have to skip to 2001.
Some stats now. Number of occurrences of "selector" per year (including "file selector", and someone who said "selector" to mean "receiver", etc):
num ratio
1998 1 3 1999 0 0 2000 2 3 2001 23 10 2002 28 5 2003 51 7 2004 70 8 2005 78 8 2006 455 39 2007 195 15 2008 74 8 2009 244 33
(where the ratio is 1000 times the number of occurrences divided by the total number of emails)
AFAIK, "selector" is vocabulary that comes from Smalltalk and its derivatives, or any "general OOP theory book" that considers Smalltalk to be a reference. This word is quite absent from the C++ vocabulary, for example. Even though I started using C++ in 1992, it took me until 1997 to read the word "selector" somewhere, probably a text on Objective-C. Starting in 2000 or so, though, I was seeing "selector" everywhere as was the norm for the Ruby language. I used it routinely on pd-list.
Instead it talks about "casting" but doesn't explain what that means (in the patch it means adding a "symbol"-selector to a meta-message). It has several vague sentences in it like: "Many objects cast the data they receive when they output it" or "Some objects do not cast the data". This doesn't make me any smarter.
trigger-help.pd is even funnier. It talks about "conversions" in which nearly every conversion results in all values of one type (0, 1, 2, 3, ...) end up being "converted" to the same value of the other type (symbol float), thus destroying the entire contents of the message (except the existence thereof).
All in all, I don't think, the patch tells you "All About Data Types". But maybe it just has a misleading name.
It's a marketing thing. It's like when you enter a "Steve's Music Store" and they tell you "if we don't have it, you don't need it".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 27 Nov 2009, Mathieu Bouchard wrote:
Some stats now. Number of occurrences of "selector" per year (including "file selector", and someone who said "selector" to mean "receiver", etc):
Btw those stats were only for pd-list and not pd-dev nor any other mailing-list. I only realised later that I hadn't said which mailing-list(s) I was talking about.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 25 Nov 2009, Frank Barknecht wrote:
Single objects unfortunatly often behave inconsistently or not as one
maybe would expect (e.g. [route list symbol] strips list- but not
symbol-selectors).[route] is quite disappointing. I already made [route2] which doesn't
modify any message, and I'm gonna make [route3] which outputs "list
$1...$n" on any non-last outlet in a consistent manner (and without the
weird quirks that happen when you try using [route] for that purpose).To one who believes that abstractions and externals should have a Pd API
that is as similar to each other, [route3] should be obvious: it would
correspond more closely to class_addmethod.all_about_data_types.pd doesn't even use the word "selector" anywhere.
The pd 0.42 source code has the word "selector" once. This word was
introduced there in 0.39. On pd-list, there have been occasional uses of
the word 'selector' quite early. There's one early mention of 'selector'
(by none other than Miller) as early as 1998, but that seems to be an
outlier. After that you have to skip to 2001.Some stats now. Number of occurrences of "selector" per year (including
"file selector", and someone who said "selector" to mean "receiver", etc):num ratio1998 1 3 1999 0 0 2000 2 3 2001 23 10 2002 28 5 2003 51 7 2004 70 8 2005 78 8 2006 455 39 2007 195 15 2008 74 8 2009 244 33
(where the ratio is 1000 times the number of occurrences divided by the
total number of emails)AFAIK, "selector" is vocabulary that comes from Smalltalk and its
derivatives, or any "general OOP theory book" that considers Smalltalk to be a reference.
I encountered this in the SICP as well which is from 1984, so probably knows its Smalltalk as well, although the index only mentions Smalltalk once in a footnote.
Here's the intro to selectors: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_idx_1290
Ciao
Frank
On Sat, 28 Nov 2009, Frank Barknecht wrote:
I encountered this in the SICP as well which is from 1984, so probably knows its Smalltalk as well, although the index only mentions Smalltalk once in a footnote. Here's the intro to selectors: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_idx_1290
This is not the same meaning of selector. We have to be careful about that. In mainstream OO vocabulary, this would be called «reader», «getter», or «accessor» (or half of an accessor), although in your example, they define these as plain functions because there is no OO in Scheme.
In Scheme, the concept of selector we are talking about does not exist. In CommonLISP, it would be called «the symbol of a generic-function» because when CommonLISP integrated the notion of OO it turned it quite inside-out.
I don't know about other OOP frameworks for LISP and Scheme but you can assume that there are as many as there are for Tcl. In those systems you may find a more ordinary concept of selector. Or not.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Nov 22, 2009, at 1:34 PM, Jonathan Wilkes wrote:
--- On Mon, 11/16/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Finding "$0" and dealing with it in messages To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Roman Haefeli" reduzierer@yahoo.de, "Phil Stone" <pkstone@ucdavis.edu
, pd-list@iem.at
Date: Monday, November 16, 2009, 8:59 PM On Mon, 16 Nov 2009, Jonathan Wilkes wrote:
--- On Mon, 11/16/09, Mathieu Bouchard matju@artengine.ca
wrote:
It doesn't work for those selectors: bang symbol
list
Why do you say it doesn't work for list?
because it doesn't.
Well, if you send the message "list 7" to [symbol] it will output "symbol list," when, according to all_about_data_types.pd, it ought to output "symbol float." Other than this, are there instances where [symbol] doesn't work correctly with lists?
I think there are. Anytime I find something like that, I make an
example patch and add it to SVN. I encourage others to add to this
collection since they are quite helpful in thinking about how we can
fix things to make them work easier:
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/doc/additional...
.hc
As far as I can tell you just need [route bang
symbol], two message boxes, and a [symbol] object. There's no need to protect the message boxes because whatever is coming out of inlet 0 and 1 of [route] is either a bang or a symbol, both of which will trigger the msg box's output without changing its content.
You are right, two [b] are extraneous. You still need [b] to protect msgbox «symbol list» from [route list].
In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element.
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
On Sun, 22 Nov 2009, Jonathan Wilkes wrote:
It doesn't work for those selectors: bang symbol list
Why do you say it doesn't work for list?
because it doesn't.
Well, if you send the message "list 7" to [symbol] it will output "symbol list," when, according to all_about_data_types.pd, it ought to output "symbol float." Other than this, are there instances where [symbol] doesn't work correctly with lists?
If you send "list stuff" or "list zzz" to [symbol] you don't get "list", you get "stuff" or "zzz".
In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element.
What's the correct selector of a 1-element list?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
--- On Fri, 11/27/09, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Finding "$0" and dealing with it in messages To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Roman Haefeli" reduzierer@yahoo.de, "Phil Stone" pkstone@ucdavis.edu, pd-list@iem.at Date: Friday, November 27, 2009, 6:23 PM On Sun, 22 Nov 2009, Jonathan Wilkes wrote:
It doesn't work for those selectors: bang
symbol list
Why do you say it doesn't work for list?
because it doesn't.
Well, if you send the message "list 7" to [symbol] it
will output "symbol list," when, according to all_about_data_types.pd, it ought to output "symbol float." Other than this, are there instances where [symbol] doesn't work correctly with lists?
If you send "list stuff" or "list zzz" to [symbol] you don't get "list", you get "stuff" or "zzz".
But how does having [route bang symbol list] instead of just [route bang symbol] help you here? [route] will call "list stuff" a symbol, not a list.
In light of what I wrote above, you'd actually need [route bang symbol float] to correctly convert lists with one float element.
What's the correct selector of a 1-element list?
Hm, I'm so used to seeing one element lists automatically converted to floats or bangs (or pointers) by just about every object I use that I would assume [symbol] ought to say "symbol float" for [list 12( and "symbol symbol" for [list foo( . But then if the selector is supposed to be "list," what should the selector be for [list( ?
-Jonathan
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Am 12.11.09 17:21 schrieb "Alexandre Porres" unter porres@gmail.com:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages.
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Without an exception at all, it should be easier to get it, as I understand.
Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Hmm, I see you have a point! But I am just used to consider "$0" and "$1, $2 ... $n" different/separate things, being "$0" solely a locality sintax.
Putting them as separate concepts I see "$1, $2 ... $n" as two different things wether in messages or objects, and that "$0" is just useless in messages.
Anyway, I am cool with what needs to be done in order to put "$0" in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all.
The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem.
I now see that uncheking "whole word" in the new version is just another "way around" rather than actually getting the Find feature to look for "$0", or even for the window number once we explicitly tell it which one it is.
So, nerverminding about "$0" in messages, I would still make a point here for the Find feature to be able to find "$0", I hope it isn't much hassle getting it to do so.
Thanks a bunch folks! Cheers alex
On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzierer@yahoo.de wrote:
Am 12.11.09 17:21 schrieb "Alexandre Porres" unter porres@gmail.com:
But I totally disagree, I have been teaching a lot basic Pd around, and
people
always get confused and think they can just throw "$0" in messages. So I
have
to state and reinforce that there is an exception that it doesn't work on messages.
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Without an exception at all, it should be easier to get it, as I understand.
Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually.
Matt
On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres porres@gmail.com wrote:
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Hmm, I see you have a point! But I am just used to consider "$0" and "$1, $2 ... $n" different/separate things, being "$0" solely a locality sintax. Putting them as separate concepts I see "$1, $2 ... $n" as two different things wether in messages or objects, and that "$0" is just useless in messages. Anyway, I am cool with what needs to be done in order to put "$0" in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking "whole word" in the new version is just another "way around" rather than actually getting the Find feature to look for "$0", or even for the window number once we explicitly tell it which one it is. So, nerverminding about "$0" in messages, I would still make a point here for the Find feature to be able to find "$0", I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex
On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzierer@yahoo.de wrote:
Am 12.11.09 17:21 schrieb "Alexandre Porres" unter porres@gmail.com:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages.
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Without an exception at all, it should be easier to get it, as I understand.
Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
hmm, I am sorry, I don't think I got what you meant... could you give an example please?
The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] & [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting "A" for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally.
cheers alex
On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrofsvl@gmail.com wrote:
Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually.
Matt
On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres porres@gmail.com wrote:
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Hmm, I see you have a point! But I am just used to consider "$0" and "$1,
$2
... $n" different/separate things, being "$0" solely a locality sintax. Putting them as separate concepts I see "$1, $2 ... $n" as two different things wether in messages or objects, and that "$0" is just useless in messages. Anyway, I am cool with what needs to be done in order to put "$0" in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the
hassle and
the problem. I now see that uncheking "whole word" in the new version is just another "way around" rather than actually getting the Find feature to look for
"$0",
or even for the window number once we explicitly tell it which one it is. So, nerverminding about "$0" in messages, I would still make a point here for the Find feature to be able to find "$0", I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex
On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzierer@yahoo.de
wrote:
Am 12.11.09 17:21 schrieb "Alexandre Porres" unter porres@gmail.com:
But I totally disagree, I have been teaching a lot basic Pd around,
and
people always get confused and think they can just throw "$0" in messages. So
I
have to state and reinforce that there is an exception that it doesn't work on messages.
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Without an exception at all, it should be easier to get it, as I understand.
Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Alexandre Porres wrote:
hmm, I am sorry, I don't think I got what you meant... could you give an example please?
The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] & [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting "A" for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally.
A frequent pd design pattern is to have a subpatch that wants to, for example, tell its own subpatch about a unique array name or receive or receive~ object.
The way this is commonly done is to make $0 of the subpatch the first argument to the subpatch's subpatch.
I am saying two things:
- Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
Matt
On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres porres@gmail.com wrote:
hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept. They could be used inside [send~] & [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just some way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting "A" for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. cheers alex
On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrofsvl@gmail.com wrote:
Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually.
Matt
On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres porres@gmail.com wrote:
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Hmm, I see you have a point! But I am just used to consider "$0" and "$1, $2 ... $n" different/separate things, being "$0" solely a locality sintax. Putting them as separate concepts I see "$1, $2 ... $n" as two different things wether in messages or objects, and that "$0" is just useless in messages. Anyway, I am cool with what needs to be done in order to put "$0" in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking "whole word" in the new version is just another "way around" rather than actually getting the Find feature to look for "$0", or even for the window number once we explicitly tell it which one it is. So, nerverminding about "$0" in messages, I would still make a point here for the Find feature to be able to find "$0", I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex
On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzierer@yahoo.de wrote:
Am 12.11.09 17:21 schrieb "Alexandre Porres" unter porres@gmail.com:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages.
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Without an exception at all, it should be easier to get it, as I understand.
Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Oh, cool, yeah, that is a nice design, I see it now.
but anyways, I still see $0 as locality and the rest as inheritance, as you are just still making a child inherit (by $1) a parent's local $0 ID.
I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
now that wasn't clear for me, but if we keep on it I suggest we might need to change the thread name maybe.
I hope this thread would stick to the point that the find feature could do a better job by finding "$0", and that "$0" could be used in messages since it is useless the way it is.
thanks alex
On Fri, Nov 13, 2009 at 6:27 PM, Matt Barber brbrofsvl@gmail.com wrote:
I am saying two things:
- Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role. I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
Matt
On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres porres@gmail.com wrote:
hmm, I am sorry, I don't think I got what you meant... could you give an example please? The way I see is that $1...$n are related to the inheritance concept.
They
could be used inside [send~] & [receive~] objects to force some sort of locality, but you can't really guarantee locality by that, it is just
some
way around that is not 100% safe, cause if you have [s $1-gain] in an abstraction, and $1 inheriting "A" for instance, a [s A-gain] object in a parent patch (or even on another opened patch) would still get the value globally. cheers alex
On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber brbrofsvl@gmail.com
wrote:
Without $0, one would have to use $1 ... $n for locality. $0 of a parent patch often needs to be passed as $1 to a child for proper locality, for instance, so I don't think they are necessarily THAT different conceptually.
Matt
On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres porres@gmail.com wrote:
Calling this an exception creates the impression, that $1 in a message is the same as in an object.
Hmm, I see you have a point! But I am just used to consider "$0" and "$1, $2 ... $n" different/separate things, being "$0" solely a locality
sintax.
Putting them as separate concepts I see "$1, $2 ... $n" as two
different
things wether in messages or objects, and that "$0" is just useless in messages. Anyway, I am cool with what needs to be done in order to put "$0" in messages, I still think it's a bit of an unnecessary hassle, but it ain't that much of a big deal after all. The thing that had no other way around was using the Find feature to actually find them, so I thought about bringing this all up: the hassle and the problem. I now see that uncheking "whole word" in the new version is just
another
"way around" rather than actually getting the Find feature to look for "$0", or even for the window number once we explicitly tell it which one it is. So, nerverminding about "$0" in messages, I would still make a point here for the Find feature to be able to find "$0", I hope it isn't much hassle getting it to do so. Thanks a bunch folks! Cheers alex
On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli reduzierer@yahoo.de wrote:
Am 12.11.09 17:21 schrieb "Alexandre Porres" unter <porres@gmail.com
:
But I totally disagree, I have been teaching a lot basic Pd around, and people always get confused and think they can just throw "$0" in messages. So I have to state and reinforce that there is an exception that it doesn't work on messages.
Calling this an exception creates the impression, that $1 in a
message
is the same as in an object.
Without an exception at all, it should be easier to get it, as I understand.
Agreed. But currently, the only thing that makes $0 in a message exceptional is the fact, that it has no meaning at all. Making it be replaced by the canvas identifier wouldn't make it less exceptional at all.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Matt Barber wrote:
I am saying two things:
- Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role.
Good points, all.
I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be on auto-repeat here.
Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different.
Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic.
roman
On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote:
Matt Barber wrote:
I am saying two things:
- Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role.
Good points, all.
I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be
Roman Haefeli wrote:
Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different.
Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic.
roman
Actually, all it would take to convert all old patches to this new form is one line of perl with a well-constructed regular expression. I agree, still, that it is probably not going to happen.
Phil
On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote:
Matt Barber wrote:
I am saying two things:
- Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role.
Good points, all.
I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)...
Someone could write their own message box object and make it do
whatever they want. Then you have both: a new interface and backwards
compatibility. The message box could just be a GUI object like any
other, there is nothing inherently unique about it.
.hc
On Nov 13, 2009, at 6:50 PM, Roman Haefeli wrote:
Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different.
Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic.
roman
On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote:
Matt Barber wrote:
I am saying two things:
- Without $0 or something similar, the only way to guarantee
similar locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm
not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some
such) by various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important
role in locality, in addition to a number of other things, and to me it
seems almost natural to use $0 as an analogy for this role.Good points, all.
I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for
message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion
not be
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote:
Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it.
It wouldn't even need to be a "GUI" object. just make it an objectbox class named [m]. Then "$1" (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff.
User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Nov 14, 2009, at 11:35 AM, Mathieu Bouchard wrote:
On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote:
Someone could write their own message box object and make it do
whatever they want. Then you have both: a new interface and
backwards compatibility. The message box could just be a GUI
object like any other, there is nothing inherently unique about it.It wouldn't even need to be a "GUI" object. just make it an
objectbox class named [m]. Then "$1" (etc) becomes the same as in
other objectboxes, and then another syntax can be used to mean
message arguments. Except that if it's not a GUI object, then it's
not clickable, and stuff.User-wise, there _is_ something inherently unique to the messagebox,
but it happens to be exactly the difference that we'd like to
eliminate.
Yeah, for clarification, there is nothing inherently unique in the
implementation. Someone could make their own message box. I'd like
to see that happen.
.hc
"Making boring techno music is really easy with modern tools," he
says, "but with live coding, boring techno is much harder." - Chris
McCormick
On Sat, 14 Nov 2009, Hans-Christoph Steiner wrote:
On Nov 14, 2009, at 11:35 AM, Mathieu Bouchard wrote:
User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate.
Yeah, for clarification, there is nothing inherently unique in the implementation.
I don't mean that it's just a user-wise thing and thus not an implementation thing. I mean that it's a user-wise thing therefore you don't have the choice to imitate it using a special implementation, if you are going to imitate it faithfully.
The $-substitution isn't run on messageboxes when they get instantiated. That's the difference I'm talking about. This is also the difference that the new messagebox wouldn't imitate, so the new-style messageboxes wouldn't need weird hacks in the pd source; but if anyone wanted to reimplement old-style messageboxes, they'd need to find a way to disable $-substitution in that case.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mathieu Bouchard wrote:
wouldn't need weird hacks in the pd source; but if anyone wanted to reimplement old-style messageboxes, they'd need to find a way to disable $-substitution in that case.
you can get the "unparsed" arguments during runtime (though after creation time) just fine. this is what every save-routine does (unless somebody decides to really save 1053 instead of $0)
masdr IOhannes
On Mon, 16 Nov 2009, IOhannes m zmölnig wrote:
Mathieu Bouchard wrote:
wouldn't need weird hacks in the pd source; but if anyone wanted to reimplement old-style messageboxes, they'd need to find a way to disable $-substitution in that case.
you can get the "unparsed" arguments during runtime (though after creation time) just fine. this is what every save-routine does (unless somebody decides to really save 1053 instead of $0)
Yes, I thought of that, but just try it, you'll see: it'll complain about missing $1, $2, etc. as you try making such messageboxes, because the $-substitution does happen anyway even if you ignore it. Even though it technically would work, no-one would want to put up with those error messages.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not).
Matt
On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote:
Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it.
It wouldn't even need to be a "GUI" object. just make it an objectbox class named [m]. Then "$1" (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff.
User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object.
On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrofsvl@gmail.com wrote:
Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not).
Matt
On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote:
Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it.
It wouldn't even need to be a "GUI" object. just make it an objectbox class named [m]. Then "$1" (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff.
User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Yeah, its great that you made this. I think people are too used to
thinking that some things are set in stone, like message boxes and
arguments. But you really can make your own. And you did it in Pd
event, bonus points there :-D
.hc
On Nov 14, 2009, at 5:45 PM, Matt Barber wrote:
There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object.
On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrofsvl@gmail.com
wrote:Here's a start -- it requires [s2l] and [l2s] from zexy, though
(there may be a way to do it vanilla, but possibly not).Matt
On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard <matju@artengine.ca
wrote: On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote:
Someone could write their own message box object and make it do
whatever they want. Then you have both: a new interface and backwards
compatibility. The message box could just be a GUI object like any other, there
is nothing inherently unique about it.It wouldn't even need to be a "GUI" object. just make it an
objectbox class named [m]. Then "$1" (etc) becomes the same as in other
objectboxes, and then another syntax can be used to mean message arguments. Except
that if it's not a GUI object, then it's not clickable, and stuff.User-wise, there _is_ something inherently unique to the
messagebox, but it happens to be exactly the difference that we'd like to eliminate._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
kill your television
Thanks. I would like to work out the bugs if anyone could find this useful... I am too trusting with [print] so there were some things with floats that were actually phantom symbols (this kind of thing is really useful for learning lessons about the weird datatype pitfalls in Pd). Here's an update.
I really wish there were some kind of [s2l] in vanilla. One COULD use something like # 2 instead of #2 and make it vanilla, but that seems kind of clunky.
MB
On Sat, Nov 14, 2009 at 6:18 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Yeah, its great that you made this. I think people are too used to thinking that some things are set in stone, like message boxes and arguments. But you really can make your own. And you did it in Pd event, bonus points there :-D
.hc
On Nov 14, 2009, at 5:45 PM, Matt Barber wrote:
There are plenty of bugs still, but this might be the type of thing one could do without having to code a new object.
On Sat, Nov 14, 2009 at 2:29 PM, Matt Barber brbrofsvl@gmail.com wrote:
Here's a start -- it requires [s2l] and [l2s] from zexy, though (there may be a way to do it vanilla, but possibly not).
Matt
On Sat, Nov 14, 2009 at 11:35 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 13 Nov 2009, Hans-Christoph Steiner wrote:
Someone could write their own message box object and make it do whatever they want. Then you have both: a new interface and backwards compatibility. The message box could just be a GUI object like any other, there is nothing inherently unique about it.
It wouldn't even need to be a "GUI" object. just make it an objectbox class named [m]. Then "$1" (etc) becomes the same as in other objectboxes, and then another syntax can be used to mean message arguments. Except that if it's not a GUI object, then it's not clickable, and stuff.
User-wise, there _is_ something inherently unique to the messagebox, but it happens to be exactly the difference that we'd like to eliminate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
kill your television
Here's my summary of the proposals mentioned here:
I agree that $0 is totally arbitrary and is not inherintly bound to
object boxes. I think this strongest proposed fix is to introduce $$
which works in both object and message boxes, its a nice parallel to
Bourne Shell syntax. On that note, I think this should also come with
Bourne Shell's $# for count of argument and $@ for a list of all
arguments. I think $$, $#, and $@ should work in both message and
object boxes. So:
messages:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
objects:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
Now, all we need is someone to code it :) I am certainly willing to
try such a patch in the Pd-extended test builds. And if it is proven
to work without causing problems, then it could be included in final
release, and hopefully work its way into Pd-vanilla as well.
I guess the place to start is someone putting together a proposal wiki
page so we can document all the details. Here's the place for it:
http://puredata.info/dev
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
Here's my summary of the proposals mentioned here:
I agree that $0 is totally arbitrary and is not inherintly bound to object boxes. I think this strongest proposed fix is to introduce $$ which works in both object and message boxes, its a nice parallel to Bourne Shell syntax. On that note, I think this should also come with Bourne Shell's $# for count of argument and $@ for a list of all arguments. I think $$, $#, and $@ should work in both message and object boxes. So:
messages:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
objects:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
Now, all we need is someone to code it :) I am certainly willing to try
i thought i had committed such a patch about 3 years ago to the sf patch tracker.
mfasr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
messages:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
objects:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
Now, all we need is someone to code it :) I am certainly willing to try
i thought i had committed such a patch about 3 years ago to the sf patch tracker.
http://sourceforge.net/tracker/?func=detail&aid=1543850&group_id=557...
i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what "bla-$@-blu" really means.
as for $$ being available in messages: i don't think this can easily be done the way things are right know.
and really, i don't think it is that important :-)
mfgasdr IOhannes
On Nov 14, 2009, at 12:17 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
messages:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
objects:
- $$ provides unique ID number
- $# provides argument count from incoming message
- $@ provides the list of arguments from incoming message
Now, all we need is someone to code it :) I am certainly willing
to tryi thought i had committed such a patch about 3 years ago to the sf
patch tracker.http://sourceforge.net/tracker/?func=detail&aid=1543850&group_id=557...
i don't know how well this works for with the new dollarg-expansion
code (within symbols, not only at the beginning). and anyhow it is unclear what "bla-$@-blu" really means.
as for $$ being available in messages: i don't think this can easily be done the way things are right know.
and really, i don't think it is that important :-)
I think this never got included because it didn't play nice with the
new dollar arg expansion code. So this patch at this point serves as
a starting point for developing this.
As for what "bla-$@-blu" means, it doesn't matter as long as $$, $@,
and $# are clearly defined. By bash rules, that would give you "bla-
my list of words-blu".
.hc
mfgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkr+5jYACgkQkX2Xpv6ydvQYYQCgjd2KBA8CqWC5fUcGLUdOMn2J +AQAoPN6GqUvAu6NmWKgOx5PU0cWdx59 =F53w -----END PGP SIGNATURE-----
Information wants to be free. -Stewart Brand
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
http://sourceforge.net/tracker/?func=detail&aid=1543850&group_id=557...
i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what "bla-$@-blu" really means.
as for $$ being available in messages: i don't think this can easily be done the way things are right know.
and really, i don't think it is that important :-)
I think this never got included because it didn't play nice with the new dollar arg expansion code.
i remember doing tests and i vaguely remember that it worked. the only thing i could imagine is, that it might not apply cleanly anymore, since both the dollarg expansion code and the $@ code both touch the same lines. but then i wrote the current expansion code before the $@,$# things (http://sourceforge.net/tracker/?func=detail&aid=1405137&group_id=557...), so i guess i might even have build on that code.
So this patch at this point serves as a
starting point for developing this.
it implements about 66% of your suggestion.
As for what "bla-$@-blu" means, it doesn't matter as long as $$, $@, and $# are clearly defined.
now what does that mean? if you implement anything, you have to make a clear definition of it (else youcouldn't express it in a language like C). you might not be aware of this fact, but you really do.
in many cases you get away with just implementing it (and a somewhat logical definition of whatever you implemented will turn out to be there)
now i did implement this and it turned out that i was wondering on what "bla-$@-blu" should be explanded to.
my experience showed me that it does matter.
i can think of 2 expansions and both make sense and both don't.
iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list.
By bash rules, that would give you "bla-my list
of words-blu".
this doosn't say much. in bash you can quote and escape. you can write bash-code that will regard "bla-my list of words-blu" to be a list of 5 arguments and bash-code that sees it as a single argument.
this is exactly the question i asked; probably this was not so clear)
gfmasd IOhannes
On Nov 14, 2009, at 3:26 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
http://sourceforge.net/tracker/?func=detail&aid=1543850&group_id=557...
i don't know how well this works for with the new dollarg-expansion
code (within symbols, not only at the beginning). and anyhow it is unclear what "bla-$@-blu" really means.as for $$ being available in messages: i don't think this can easily be done the way things are right know.
and really, i don't think it is that important :-)
I think this never got included because it didn't play nice with
the new dollar arg expansion code.i remember doing tests and i vaguely remember that it worked. the only thing i could imagine is, that it might not apply cleanly anymore, since both the dollarg expansion code and the $@ code both touch the same lines. but then i wrote the current expansion code before the $@,$# things (http://sourceforge.net/tracker/?func=detail&aid=1405137&group_id=557... ), so i guess i might even have build on that code.
So this patch at this point serves as a
starting point for developing this.
it implements about 66% of your suggestion.
As for what "bla-$@-blu" means, it doesn't matter as long as $$,
$@, and $# are clearly defined.now what does that mean? if you implement anything, you have to make a clear definition of it (else youcouldn't express it in a language like C). you might not be aware of this fact, but you really do.
in many cases you get away with just implementing it (and a somewhat logical definition of whatever you implemented will turn out to be
there)now i did implement this and it turned out that i was wondering on
what "bla-$@-blu" should be explanded to.my experience showed me that it does matter.
i can think of 2 expansions and both make sense and both don't.
iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will
always expand to a list.By bash rules, that would give you "bla-my list
of words-blu".
this doosn't say much. in bash you can quote and escape. you can write bash-code that will regard "bla-my list of words-blu" to be a list of 5 arguments and bash-code that sees it as a single
argument.this is exactly the question i asked; probably this was not so clear)
I think omitting something here because you don't think its useful is
not a good idea. Instead, I think $@ should always expand unless that
causes problems somewhere. That's the spirit of flexibility that
makes Pd good.
.hc
kill your television
Hans-Christoph Steiner wrote:
this is exactly the question i asked; probably this was not so clear)
I think omitting something here because you don't think its useful is not a good idea. Instead, I think $@ should always expand unless that causes problems somewhere. That's the spirit of flexibility that makes Pd good.
i think you totally misunderstand me.
$@ is implemented, this is not the problem. the question i was asking is, what this will produce:
[1 2 3( | [mymsg bla-$@-blu(
i see 2 possibilities, and both seem weird. they seem weirder when comparing them to single $@, like in [mymsg $@ $@(
fmgasdr IOhannes
it really seems to me like this is something i have spent little thought on and you have spent no thought on and now we try to discuss it.
IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list.
i guess this is the main source of misunderstanding.
with "dollsym" i really mean what Pd internally understands as A_DOLLSYM, that is a symbol constructed with a dollar+number and something else, e.g. "$1_bla" or "/foo/$2/bla" but not an A_DOLLARG, which is a a dollar+number, e.g. "$1".
A_DOLLSYM will always expand to symbol, whereas A_DOLLARG will expand to an atom of the type of the referenced listelement. e.g. [10 20 30( | [$2(
will give you the float "20".
whereas [10 20 30( | [/$1(
will give you the symbol '/20'
now in the current implementation we have:
[10 20 30( | [$@ $@(
which gives you a 6 element list "10 20 30 10 20 30".
but what is this supposed to give me?
[10 20 30( | [$@/$@(
either its a 5 element list "10 20 30/10 20 30" (with 4 floats and a symbol inbetween) or it is a single symbol '10 20 30/10 20 30'.
i don't like the former very much, because it generates both symbols and other atoms in a hard to predict matter, and is kind of out of sync with pd's ordinary behaviour.
i don't like the latter very much, because it suddenly allows easy creation of symbols with spaces, and i think Pd is not really ready for that.
symbols with spaces is not something one cannot live without. (we all have learned to do this by now). even if we can live with a symbol-with-spaces approach, this wouldn't allow for "just" symbol with spaces (the thing [l2s] does), opening another can of worms.
therefore my conclusion was that it was better *for now* to only support A_DOLLARG "$@" but not in A_DOLLSYM. i don't even know whether i have implemented this conclusion or whether i just went with one of the 2 options.
read the code.
fgmadsr IOhannes
On Sun, 15 Nov 2009, IOhannes m zmoelnig wrote:
with "dollsym" i really mean what Pd internally understands as A_DOLLSYM, that is a symbol constructed with a dollar+number and something else, e.g. "$1_bla" or "/foo/$2/bla" but not an A_DOLLARG, which is a a dollar+number, e.g. "$1".
It's really a Dollar and not a Doll Arg.
Though you could ask why is it a Doll Sym and not a Dollar Symbol...
And why Dollar when the "$" character is "$" because it looks like the "S" in "Substitute"...
Anyway, in <m_pd.h>, A_DOLLAR exists and A_DOLLARG doesn't.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mathieu Bouchard wrote:
Anyway, in <m_pd.h>, A_DOLLAR exists and A_DOLLARG doesn't.
ah yes thanks for fixing.
mfgws.g IOhannes
2009/11/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
http://sourceforge.net/tracker/?func=detail&aid=1543850&group_id=557...
i don't know how well this works for with the new dollarg-expansion code (within symbols, not only at the beginning). and anyhow it is unclear what "bla-$@-blu" really means.
as for $$ being available in messages: i don't think this can easily be done the way things are right know.
and really, i don't think it is that important :-)
I think this never got included because it didn't play nice with the new dollar arg expansion code.
i remember doing tests and i vaguely remember that it worked. the only thing i could imagine is, that it might not apply cleanly anymore, since both the dollarg expansion code and the $@ code both touch the same lines.
Haha, I have no idea if I ever publicized this or not, but I believe I got this applying to 0.42+ back in April... Haven't tested this since then but if it applies I'll add it to the tracker.
Best Luke
but then i wrote the current expansion code before the $@,$# things (http://sourceforge.net/tracker/?func=detail&aid=1405137&group_id=557...), so i guess i might even have build on that code.
So this patch at this point serves as a
starting point for developing this.
it implements about 66% of your suggestion.
As for what "bla-$@-blu" means, it doesn't matter as long as $$, $@, and $# are clearly defined.
now what does that mean? if you implement anything, you have to make a clear definition of it (else youcouldn't express it in a language like C). you might not be aware of this fact, but you really do.
in many cases you get away with just implementing it (and a somewhat logical definition of whatever you implemented will turn out to be there)
now i did implement this and it turned out that i was wondering on what "bla-$@-blu" should be explanded to.
my experience showed me that it does matter.
i can think of 2 expansions and both make sense and both don't.
iirc, my final conclusion was that it would be best to not allow $@ expansion at all for dollsyms, but just as solitary $@ which will always expand to a list.
By bash rules, that would give you "bla-my list
of words-blu".
this doosn't say much. in bash you can quote and escape. you can write bash-code that will regard "bla-my list of words-blu" to be a list of 5 arguments and bash-code that sees it as a single argument.
this is exactly the question i asked; probably this was not so clear)
gfmasd IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkr/El8ACgkQkX2Xpv6ydvRZdwCgsbV3Eh85Nyw8cwqgFdeorNnx UkMAoKTGZ0NOEzu/nKyZ+gJ//8vnqx7M =S6J0 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Porres -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
jurgen -
Justin Glenn Smith -
Luke Iannini -
Mathieu Bouchard -
Matt Barber -
Phil Stone -
Roman Haefeli -
ypatios