I have written some classes for handling arguments when writing classes in Pd. They are [float_argument], [symbol_argument], and [any_argument]. Currently, I am thinking in general, inlets should be matched to arguments and vice versa, so these objects all have a "convenience" right inlet, to attach the [inlet] to so that the data all comes from the [*_argument] object.
To use them, you add the argument you want it to handle like this:
[float_argument $1]
If you want a default value for when none is specified, you would do it like this:
[float_argument $2 234] [symbol_argument $3 default] [any_argument $9 asdf] [any_argument $5 444]
My goal is to make these a standard way of handling arguments when writing classes in Pd. What do y'all think?
Also, I am trying to think of a library name in which these would belong. foundation? support? core? patching? language?
.hc
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it."
- Thomas
Jefferson
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I have written some classes for handling arguments when writing classes in Pd. They are [float_argument], [symbol_argument], and [any_argument]. Currently, I am thinking in general, inlets should be matched to arguments and vice versa,
"should match" would be oversimplyfiying, but having an extra inlet in the argument-patches never hurts.
so these objects all have a "convenience" right inlet, to attach the [inlet] to so that the data all comes from the [*_argument] object.
To use them, you add the argument you want it to handle like this:
[float_argument $1]
If you want a default value for when none is specified, you would do it like this:
[float_argument $2 234] [symbol_argument $3 default] [any_argument $9 asdf] [any_argument $5 444]
I attached "list_argument" which does the same as "any_argument" but doesn't require any externals and is much simpler than [any_arg...]. In fact, it's just [float_argument] where "float" is replaced by "list append".
Note that I would much prefer, if [list_argument] would be renamed to be [any_argument] and replace it.
Reason is: The name "list_argument" could lead to wrong expectations: It doesn't handle variable length lists as arguments, because that is impossible without externals like dollarg. It just handles one-element lists which get auto-converted to their respective type: "symbol x" or "float x".
Of course it won't work with Pd < 0.39.
Regarding symbol_- and float_argument: These could be implemented as:
[list_argument $1 $2] or [any_argument] | [route symbol] or [route float] | [outlet]
to share more code. Because Pd autoconverts one-element lists, there will always be a proper selector to make [route] do The Right Thing.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jan 31, 2006, at 6:16 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I have written some classes for handling arguments when writing
classes in Pd. They are [float_argument], [symbol_argument], and [any_argument]. Currently, I am thinking in general, inlets should
be matched to arguments and vice versa,"should match" would be oversimplyfiying, but having an extra inlet in the argument-patches never hurts.
I mean in general, but of course, there should be room for exceptions.
so these objects all have a "convenience" right inlet, to attach the [inlet] to so that the data all comes from the [*_argument] object.
To use them, you add the argument you want it to handle like this:
[float_argument $1]
If you want a default value for when none is specified, you would do
it like this:[float_argument $2 234] [symbol_argument $3 default] [any_argument $9 asdf] [any_argument $5 444]
I attached "list_argument" which does the same as "any_argument" but doesn't require any externals and is much simpler than [any_arg...]. In fact, it's just [float_argument] where "float" is replaced by "list append".
Note that I would much prefer, if [list_argument] would be renamed to be [any_argument] and replace it.
Reason is: The name "list_argument" could lead to wrong expectations:
It doesn't handle variable length lists as arguments, because that is impossible without externals like dollarg. It just handles one-element lists which get auto-converted to their respective type: "symbol x" or "float x".Of course it won't work with Pd < 0.39.
Regarding symbol_- and float_argument: These could be implemented as:
[list_argument $1 $2] or [any_argument] | [route symbol] or [route float] | [outlet]
to share more code. Because Pd autoconverts one-element lists, there will always be a proper selector to make [route] do The Right Thing.
[list_anything] looks good, fine by me if it becomes [any_argument].
But the question I have now is what should we call this library? I
plan on writing a lot of objects that make it easier to write objects
in Pd. Here are some random ideas on names:
foundation support language
hmm... none of them seem great to me...
.hc
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it."
- Thomas
Jefferson
On Jan 31, 2006, at 6:16 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I have written some classes for handling arguments when writing classes in Pd. They are [float_argument], [symbol_argument], and [any_argument]. Currently, I am thinking in general, inlets should be matched to arguments and vice versa,
"should match" would be oversimplyfiying, but having an extra inlet in the argument-patches never hurts.
so these objects all have a "convenience" right inlet, to attach the [inlet] to so that the data all comes from the [*_argument] object.
To use them, you add the argument you want it to handle like this:
[float_argument $1]
If you want a default value for when none is specified, you would do it like this:
[float_argument $2 234] [symbol_argument $3 default] [any_argument $9 asdf] [any_argument $5 444]
I attached "list_argument" which does the same as "any_argument" but doesn't require any externals and is much simpler than [any_arg...]. In fact, it's just [float_argument] where "float" is replaced by "list append".
Note that I would much prefer, if [list_argument] would be renamed to be [any_argument] and replace it.
Reason is: The name "list_argument" could lead to wrong expectations: It doesn't handle variable length lists as arguments, because that is impossible without externals like dollarg. It just handles one-element lists which get auto-converted to their respective type: "symbol x" or "float x".
Of course it won't work with Pd < 0.39.
Regarding symbol_- and float_argument: These could be implemented as:
[list_argument $1 $2] or [any_argument] | [route symbol] or [route float] | [outlet]
to share more code. Because Pd autoconverts one-element lists, there will always be a proper selector to make [route] do The Right Thing.
I found one key difference between [any_argument] and [list_argument].
[any_argument] outputs a non-symbol, [list_argument] outputs a symbol.
So that means that if you want to handle messages like [word( with
[list_argument], there will have to be this after it:
[route symbol] | [route word]
Personally, I think its better having the argument not be a symbol since its very likely that [route] will be involved soon after. Also, for [list_argument], you'll need some extra logic on the convenience inlet to make sure that the output on the [outlet] is always consistent. I attached a version of [list_argument] with this extra logic:
[inlet] | [route float] \ [symbol] \ / \ / \ / [outlet]
This gets into another definition question. What is the type in this
message: [word( Its not a "not-list list" since its not a list of any
kind. Pd itself doesn't call one element messages a "list". And a
"non-list element" would also include this: [5(. So I guess its an
"undefined element" to match "undefined lists".
So we have: bang float symbol list pointer undefined element undefined list
I guess we should just coin words for these, like undelement and
undlist ;) Let's check the thesaurus for list: inventory; or element:
item, unit. Or how about this: "untyped list" and "untyped element".
.hc
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I found one key difference between [any_argument] and [list_argument].
[any_argument] outputs a non-symbol, [list_argument] outputs a symbol.
That's a tricky question: What would a user of these abstractions expect [*_argument] to output if s/he creates an abstraction with the argument [myabs foo]? Should "foo" be a "foo" or a "symbol foo"? Both cases are quite usual, but they look the same from the argument handling.
For consistency I would say: If the user wants "foo" but not "symbol foo" s/he shouold take care of that manually with [list trim].
So that means that if you want to handle messages like [word( with [list_argument], there will have to be this after it:
[route symbol] | [route word]
better would be [list trim].
Personally, I think its better having the argument not be a symbol since its very likely that [route] will be involved soon after.
Or [makefilename pd-%s] ;)
Also, for [list_argument], you'll need some extra logic on the convenience inlet to make sure that the output on the [outlet] is always consistent. I attached a version of [list_argument] with this extra logic:
[inlet] | [route float] \ [symbol] \ / \ / \ / [outlet]
If this coercion to a type is wanted, a simple [list] would be better IMO.
This gets into another definition question. What is the type in this
message: [word(
It's a symbol. Oh, no, wait, it's not, "symbol word" would be a symbol, or rather, a symbol-symbol. [word( then would be a non-symbol-symbol. ;)
If you send it through [list] it will always become a symbol-symbol.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 4 Feb 2006, Frank Barknecht wrote:
That's a tricky question: What would a user of these abstractions expect [*_argument] to output if s/he creates an abstraction with the argument [myabs foo]? Should "foo" be a "foo" or a "symbol foo"? Both cases are quite usual, but they look the same from the argument handling.
Pd's pseudoobjects include floatatom (Ctrl+3) and symbolatom (Ctrl+4).
Note that both of those are named with "atom" in the name. Those names are
part of the Pd file format. The symbolatom boxes output "symbol foo" and
not "foo", because they output something that can be auto-converted to a
1-element list.
For consistency I would say: If the user wants "foo" but not "symbol foo" s/he shouold take care of that manually with [list trim].
I agree.
This gets into another definition question. What is the type in this message: [word(
It's a symbol. Oh, no, wait, it's not, "symbol word" would be a symbol, or rather, a symbol-symbol. [word( then would be a non-symbol-symbol. ;)
There are "atom messages" which is any message that has the "list" selector and one argument, or anything that can be cast to/from it. This includes messages with "float" "symbol" "pointer" selectors.
There are "listlike messages" which may be any message that has the "list" selector or can be cast to/from it. This includes atom messages and the bang message.
The rest may be called "nonlistlike messages" and everything together may be called "messages".
Your "non-symbol-symbol" could be called "nonlistlike messages without arguments" (or "messages without arguments" in order to include bang), but it wouldn't have that Alice-in-Wonderland sound that "non-symbol-symbol" has.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
There are "atom messages" which is any message that has the "list" selector and one argument, or anything that can be cast to/from it. This includes messages with "float" "symbol" "pointer" selectors.
There are "listlike messages" which may be any message that has the "list" selector or can be cast to/from it. This includes atom messages and the bang message.
The rest may be called "nonlistlike messages" and everything together may be called "messages".
Your "non-symbol-symbol" could be called "nonlistlike messages without arguments" (or "messages without arguments" in order to include bang), but it wouldn't have that Alice-in-Wonderland sound that "non-symbol-symbol" has.
But "Alice in Wonderland" is what I'm aiming for! ;)
Nevertheless I think, the nomenclature you suggest sounds very reasonable.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 4 Feb 2006, Frank Barknecht wrote:
But "Alice in Wonderland" is what I'm aiming for! ;)
A List in Wonderland meets the #ffffff Rabbit. A list in a pool of ears. A list meets the TODO bird. A list grows larger (by [prepend]). Meets a Pentium-smoking caterpillar and plays croquet with the queen of arts. "Off with her head!" said the queen, and so a list was quickly processed by [list-split 1].
Sorry.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 4, 2006, at 4:25 AM, Mathieu Bouchard wrote:
On Sat, 4 Feb 2006, Frank Barknecht wrote:
That's a tricky question: What would a user of these abstractions
expect [*_argument] to output if s/he creates an abstraction with the
argument [myabs foo]? Should "foo" be a "foo" or a "symbol foo"? Both cases are quite usual, but they look the same from the argument handling.Pd's pseudoobjects include floatatom (Ctrl+3) and symbolatom (Ctrl+4). Note that both of those are named with "atom" in the name. Those names
are part of the Pd file format. The symbolatom boxes output "symbol foo"
and not "foo", because they output something that can be auto-converted to
a 1-element list.For consistency I would say: If the user wants "foo" but not "symbol foo" s/he shouold take care of that manually with [list trim].
I agree.
This gets into another definition question. What is the type in this message: [word(
It's a symbol. Oh, no, wait, it's not, "symbol word" would be a symbol, or rather, a symbol-symbol. [word( then would be a non-symbol-symbol. ;)
There are "atom messages" which is any message that has the "list" selector and one argument, or anything that can be cast to/from it.
This includes messages with "float" "symbol" "pointer" selectors.There are "listlike messages" which may be any message that has the
"list" selector or can be cast to/from it. This includes atom messages and the bang message.The rest may be called "nonlistlike messages" and everything together
may be called "messages".Your "non-symbol-symbol" could be called "nonlistlike messages without arguments" (or "messages without arguments" in order to include bang),
but it wouldn't have that Alice-in-Wonderland sound that
"non-symbol-symbol" has.
I outlined these categories because each one has distinct behavior, so
each one should have a distinct name:
bang float symbol pointer undefined element list undefined list
Data types are different than messages. Anyone of these categories can
be a message, and they can stand alone without being a message, like in
a symbolatom or floatatom. When you have something stored in a
[symbol], [float], [any], etc. then its not a message, but just data.
So I don't think we should definite data types in terms of messages.
The terms that you come up with work as general categories, but they do
not help in defining the very specific types I listed above, as data
types, not as messages. (FYI: Miller uses the terms "out-of-band
messages" and "metamessages" in list-help.pd).
That still leaves "undefined element" and "undefined list" as, um,
undefined...
.hc
There is no way to peace, peace is the way.
-A.J. Muste
On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
I outlined these categories because each one has distinct behavior, so each one should have a distinct name:
bang float symbol pointer undefined element
As an atom type, undefined element does not exist. (Incidentally, out of 12 values of t_atomtype, only 7 are real atom types and only 3 may travel along wires).
As an atom variable, like [float] and [symbol] and [pointer], if "undefined element" is meant to be any of those three, then it can exist, because an atom can be of only one of those types at once, while an atom variable may decide to hold whichever values it wants to accept.
When you have something stored in a [symbol], [float], [any], etc. then its not a message, but just data. So I don't think we should definite data types in terms of messages.
definite? define?
I think that there should be clear rules about mapping atoms (data) back to messages... and that's why I'm talking about atom messages.
The terms that you come up with work as general categories, but they do not help in defining the very specific types I listed above, as data types, not as messages.
Since when is bang a datatype?
And is "type" as an indicator of what a piece of data is, or an indicator of what the accepted data could be?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 4, 2006, at 3:37 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I found one key difference between [any_argument] and [list_argument]. [any_argument] outputs a non-symbol, [list_argument] outputs a symbol.
That's a tricky question: What would a user of these abstractions expect [*_argument] to output if s/he creates an abstraction with the argument [myabs foo]? Should "foo" be a "foo" or a "symbol foo"? Both cases are quite usual, but they look the same from the argument handling.
For consistency I would say: If the user wants "foo" but not "symbol foo" s/he shouold take care of that manually with [list trim].
I think we can keep both [any_argument] and [list_argument] so that you
can choose the behavior. Also its very easily and logically
straightforward to do this if you want:
[any_argument] | [route float] [symbol]
And this will work even with very old versions of Pd and would be
compatible with [list_argument].
So that means that if you want to handle messages like [word( with [list_argument], there will have to be this after it:
[route symbol] | [route word]
better would be [list trim].
In my opinion, new is not always better. The double [route] thing
works fine, and it is a clearly established method. [list] is still
quite new, so for things like [*_arguments], I think its wise to stick
to tried-and-true methods whenever possible.
Personally, I think its better having the argument not be a symbol since its very likely that [route] will be involved soon after.
Or [makefilename pd-%s] ;)
Also, for [list_argument], you'll need some extra logic on the convenience inlet to make sure that the output on the [outlet] is always consistent. I attached a version of [list_argument] with this extra logic:
[inlet] | [route float] \ [symbol] \ / \ / \ / [outlet]
If this coercion to a type is wanted, a simple [list] would be better IMO.
Hmm, I am beginning to think that parts of [list] could be implemented
in Pd 0.38.4, like this type conversion part. Hmm...
.hc
This gets into another definition question. What is the type in this message: [word(
It's a symbol. Oh, no, wait, it's not, "symbol word" would be a symbol, or rather, a symbol-symbol. [word( then would be a non-symbol-symbol. ;)
If you send it through [list] it will always become a symbol-symbol.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, I am beginning to think that parts of [list] could be implemented
in Pd 0.38.4, like this type conversion part. Hmm...
Wait till you see how Graph on Parent was improved in 0.39. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Feb 4, 2006, at 2:17 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, I am beginning to think that parts of [list] could be implemented in Pd 0.38.4, like this type conversion part. Hmm...
Wait till you see how Graph on Parent was improved in 0.39. ;)
Yes, that is much better, I am not opposed to 0.39, my point was that
you can implement a lot of the functionality that's in [list] in Pd
itself (i.e. not using [list], i.e. Pd <= 0.38.4).
Actually, I really want to get 0.38.4-extended released, so I can move
on... that will happen soon...
.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
Hans-Christoph Steiner wrote:
On Feb 4, 2006, at 3:37 AM, Frank Barknecht wrote:
For consistency I would say: If the user wants "foo" but not "symbol foo" s/he shouold take care of that manually with [list trim].
I think we can keep both [any_argument] and [list_argument] so that you
can choose the behavior. Also its very easily and logically
straightforward to do this if you want:[any_argument] | [route float] [symbol]
i think [any_argument] is bad by design. as far as i understand list vs. selectors, "lists" (the atoms after the selector) are the data, whereas the "selector" is attached to a function (e.g. the selector will define how an object will process the data)
arguments to an object are always data for this object (even though they might influence the way the object handles other data), therefore they cannot be non list-lists. (arguments to an object can never be messages because of the timish nature of messages (appearing now....and now) - however messages can have data which can be used by an ojbect just like its arguments)
i think most bad things with nonlistlike messages arise from the use of the selector as _data_.
(and sometimes messages become nonlistlike messages (by the use of say [route]) just to simple)
So that means that if you want to handle messages like [word( with [list_argument], there will have to be this after it:
[route symbol] | [route word]
better would be [list trim].
In my opinion, new is not always better. The double [route] thing
works fine, and it is a clearly established method. [list] is still
quite new, so for things like [*_arguments], I think its wise to stick
to tried-and-true methods whenever possible.
i don't understand this arguing. using pd objects is not like watering flowers: objects are supposed to work within their little well defined world, and objects of the high complexity of [route] and [list] normally don't need generations of evolution to become what they are. after all, since [route]s behaviour has changed a bit as to what type is output, i guess using [list] would even be more stable.
the only reason to not use [list] is compatibility with older pd versions (but i also advise to use pd-0.39)
Personally, I think its better having the argument not be a symbol since its very likely that [route] will be involved soon after.
how comes? for me it is more likely to have a [symbol] (or nowadays: [list]) involved whenever a symbol by chance becomes a message without arguments.
mfg.adsr IOhannes
On Sat, 4 Feb 2006, IOhannes m zmoelnig wrote:
arguments to an object are always data for this object (even though they might influence the way the object handles other data), therefore they cannot be non list-lists.
Yes. If a list has to be broken down into single elements, it should be as "atom messages", that is, in a form castable to 1-element list-lists.
i think most bad things with nonlistlike messages arise from the use of the selector as _data_. (and sometimes messages become nonlistlike messages (by the use of say [route]) just to simple)
In other words, [route] is consistent with messageboxes' list shortcut (of not having to write "list" if the message starts with a float) and it is so by not being consistent with Pd's internals. That something as basic as [route] behaves in such a way is misleading about Pd's messaging model and is source of confusion.
I suggest that a new [list route] object be created that would do like [route] except that it wouldn't accept nonlistlike messages and would always route according to $1 and not according to sometimes the $1 and sometimes the selector.
the only reason to not use [list] is compatibility with older pd versions (but i also advise to use pd-0.39)
Yes. Backwards compatibility is nice, but it makes a lot more sense to pay attention to backwards compatibility when there is a solid base of features such that new features aren't so compelling that one wants to depend on them.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
I think we can keep both [any_argument] and [list_argument] so that you can choose the behavior. Also its very easily and logically straightforward to do this if you want:
[any_argument] | [route float] [symbol]
And this will work even with very old versions of Pd and would be compatible with [list_argument].
This wouldn't work with pointers. This also wouldn't work if Pd's set of basic atomtypes (float symbol pointer) gets extended to more types in the future.
In my opinion, new is not always better. The double [route] thing works fine, and it is a clearly established method. [list] is still quite new, so for things like [*_arguments], I think its wise to stick to tried-and-true methods whenever possible.
tried-and-true is ok if the new [list] thingy doesn't fill a gap in Pd. But it does fill a big gap, such that anything designed for >=0.39 which avoids using [list] is just being retro. It's not like [list] is some kind of luxury, isn't it?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 4, 2006, at 3:58 PM, Mathieu Bouchard wrote:
On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
I think we can keep both [any_argument] and [list_argument] so that
you can choose the behavior. Also its very easily and logically
straightforward to do this if you want:[any_argument] | [route float] [symbol]
And this will work even with very old versions of Pd and would be
compatible with [list_argument].This wouldn't work with pointers. This also wouldn't work if Pd's set
of basic atomtypes (float symbol pointer) gets extended to more types in
the future.In my opinion, new is not always better. The double [route] thing
works fine, and it is a clearly established method. [list] is still quite new, so for things like [*_arguments], I think its wise to stick to tried-and-true methods whenever possible.tried-and-true is ok if the new [list] thingy doesn't fill a gap in Pd. But it does fill a big gap, such that anything designed for >=0.39
which avoids using [list] is just being retro. It's not like [list] is some
kind of luxury, isn't it?
Ok, I'm convinced on that point, [list_argument] should use list. I
support backwards compatibility only if it doesn't affect forward
compatibility. My concern is that since [list] is new an untested, and
something of a hack (i.e. alist_class) that is might have to change
behavior at some point in the future. It doesn't feel stable to me
yet.
But I still think that [any_argument] that outputs a non-symbol is
useful too. How about this: [list_argument] becomes [any_argument],
since its symbol output matches [symbol_argument], then the non-list
[any_argument] is [route_argument] or something like that.
.hc
There is no way to peace, peace is the way.
-A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Ok, I'm convinced on that point, [list_argument] should use list. I
support backwards compatibility only if it doesn't affect forward
compatibility. My concern is that since [list] is new an untested,
Objection, judge! ;) It isn't untested: At least in my patches I use it all the time since it first appeared in Pd. It never crashed Pd, it always does, what it is supposed to do and I use it a lot more often than I use for example [symbol]. Plus: the [list]-abs collection could be seen as a comprehensive test-suite just for [list], which is something, many other objects don't have yet.
But I still think that [any_argument] that outputs a non-symbol is
useful too.
But that's easy to achieve using [list trim], if needed. Of course one could make another abstraction which includes this, like [any|list_argument_trimmed] but I really don't see this as a necessity.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Feb 5, 2006, at 12:40 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Ok, I'm convinced on that point, [list_argument] should use list. I support backwards compatibility only if it doesn't affect forward compatibility. My concern is that since [list] is new an untested,
Objection, judge! ;) It isn't untested: At least in my patches I use it all the time since it first appeared in Pd. It never crashed Pd, it always does, what it is supposed to do and I use it a lot more often than I use for example [symbol]. Plus: the [list]-abs collection could be seen as a comprehensive test-suite just for [list], which is something, many other objects don't have yet.
[list] is untested as compared to [route]. By untested, I don't mean
bugs, but rather whether as a paradigm it makes sense in all possible
ways. There are already a lot of odd things with Pd's message
handling, it'd would be bad to introduce more.
But I still think that [any_argument] that outputs a non-symbol is useful too.
But that's easy to achieve using [list trim], if needed. Of course one could make another abstraction which includes this, like [any|list_argument_trimmed] but I really don't see this as a necessity.
Ok, ok, I'll use [list] ;).
But that makes me think, (non-sequeteur warning) what type of data does
this output:
[symbol arg!( | [list trim] |
;)
.hc
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
[list] is untested as compared to [route]. By untested, I don't mean bugs, but rather whether as a paradigm it makes sense in all possible ways. There are already a lot of odd things with Pd's message handling, it'd would be bad to introduce more.
[route] hasn't been tested and it doesn't make sense as a paradigm. Neither does [trigger]. So what is it about all those double standards?
what type of data does this output: [symbol arg!( | [list trim]
depends on how you (re)define the word data and the word type to suit your fancy.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 30 Jan 2006, Hans-Christoph Steiner wrote:
My goal is to make these a standard way of handling arguments when writing classes in Pd. What do y'all think?
I think that if Pd had MAX's [patcherargs] then it would be a first step towards getting out of the stone age.
From there it'd be possible to make one abstr on top of that, which would handle all arguments at once and ensure respect of common set/bang/get methods in inlet 0.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 4, 2006, at 4:05 AM, Mathieu Bouchard wrote:
On Mon, 30 Jan 2006, Hans-Christoph Steiner wrote:
My goal is to make these a standard way of handling arguments when writing classes in Pd. What do y'all think?
I think that if Pd had MAX's [patcherargs] then it would be a first
step towards getting out of the stone age.
I don't entirely get how it works, looking at the help patch. What are
the "attributes"? Is [patcherargs 10 20] like this: [float $1] [float
$2]?
From there it'd be possible to make one abstr on top of that, which
would handle all arguments at once and ensure respect of common set/bang/get methods in inlet 0.
It seems to be a black box, which I am not a fan of. I think we can do
it cleaner and do it mostly in Pd.
.hc ________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
I don't entirely get how it works, looking at the help patch. What are the "attributes"?
Attributes are specific to Flext/Pyext, although GridFlow has a variant on this concept. It's not used in Pd. It's like what's called Keyword Arguments in several languages like Python and CommonLisp, and it's like the dash options in Tcl (though in Tcl it's not a language feature, just a convention).
Is [patcherargs 10 20] like this: [float $1] [float $2]?
I guess so, except that $1 defaults to 10, instead of defaulting to 0, or worse, instead that whenever $1 is 0, it gets replaced by 10...
[patcherargs] seems to allow any number of arguments in the parent patch and so can be used to support varargs abstractions, something that plain Pd can't because you can't even know how many args you really have.
Plus, [patcherargs] gives it as a list, which is then easy to process using [list] (and that's something that Frank will love).
It seems to be a black box, which I am not a fan of. I think we can do it cleaner and do it mostly in Pd.
I'm trying to say that Pd is broken and that [patcherargs] is cleaner...
It wouldn't need to have the "attributes" part available, so you could drop the second outlet and then it would be a very small and simple external whose code fits on a page. Of course I think it should be internal.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 4, 2006, at 3:51 PM, Mathieu Bouchard wrote:
On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
I don't entirely get how it works, looking at the help patch. What
are the "attributes"?Attributes are specific to Flext/Pyext, although GridFlow has a
variant on this concept. It's not used in Pd. It's like what's called Keyword Arguments in several languages like Python and CommonLisp, and it's
like the dash options in Tcl (though in Tcl it's not a language feature,
just a convention).Is [patcherargs 10 20] like this: [float $1] [float $2]?
I guess so, except that $1 defaults to 10, instead of defaulting to 0,
or worse, instead that whenever $1 is 0, it gets replaced by 10...[patcherargs] seems to allow any number of arguments in the parent
patch and so can be used to support varargs abstractions, something that
plain Pd can't because you can't even know how many args you really have.Plus, [patcherargs] gives it as a list, which is then easy to process using [list] (and that's something that Frank will love).
It seems to be a black box, which I am not a fan of. I think we can
do it cleaner and do it mostly in Pd.I'm trying to say that Pd is broken and that [patcherargs] is
cleaner...It wouldn't need to have the "attributes" part available, so you could drop the second outlet and then it would be a very small and simple external whose code fits on a page. Of course I think it should be internal.
[float_argument], [symbol_argument], and [any_argument] (previously
[list_argument]) can do defaults like this: [symbol_argument $1
default] so we already got that part of [patcherargs] covered.
As for using an indeterminate amount of arguments, I think that would
be better supported using $# and $@ in Pd (or perhaps $argc and $argv).
.hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
[float_argument], [symbol_argument], and [any_argument] (previously [list_argument]) can do defaults like this: [symbol_argument $1 default] so we already got that part of [patcherargs] covered.
As for using an indeterminate amount of arguments, I think that would be better supported using $# and $@ in Pd (or perhaps $argc and $argv).
If you believe that abstractions are better than externals, I would suppose that it also implies that externals are better than new syntax. After all, an external is usable by all right now, whereas modifying pd is somewhat more troublesome.
Now tell me, why do you like $# and $@ over [patcherargs] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 5, 2006, at 2:35 PM, Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
[float_argument], [symbol_argument], and [any_argument] (previously [list_argument]) can do defaults like this: [symbol_argument $1
default] so we already got that part of [patcherargs] covered.As for using an indeterminate amount of arguments, I think that would
be better supported using $# and $@ in Pd (or perhaps $argc and $argv).If you believe that abstractions are better than externals, I would suppose that it also implies that externals are better than new syntax. After all, an external is usable by all right now, whereas modifying pd is somewhat more troublesome.
Now tell me, why do you like $# and $@ over [patcherargs] ?
Languages that provide arguments generally provide argc and argv. I
think Pd should too.
C, C++ has argc, argv Java has args.getLength, String[] args bourne shell has $#, $@ C shell has $#argv, $argv Perl has $#argv, @argv
.hc
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
Now tell me, why do you like $# and $@ over [patcherargs] ?
Languages that provide arguments generally provide argc and argv. I think Pd should too. C, C++ has argc, argv Java has args.getLength, String[] args bourne shell has $#, $@ C shell has $#argv, $argv Perl has $#argv, @argv
It could be an object class called [args] too, no? (I don't like the name [patcherargs] because not all patchers have args nor a t_canvasenvironment).
PS: none of the above languages have [float_argument] ;-)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
Now tell me, why do you like $# and $@ over [patcherargs] ?
Languages that provide arguments generally provide argc and argv. I think Pd should too. C, C++ has argc, argv Java has args.getLength, String[] args bourne shell has $#, $@ C shell has $#argv, $argv Perl has $#argv, @argv
It could be an object class called [args] too, no? (I don't like the name
btw, there is an object [dollarg] in iemlib that does exactly this.
mf.asd.r IOhannes
On Feb 5, 2006, at 4:01 PM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
Now tell me, why do you like $# and $@ over [patcherargs] ?
Languages that provide arguments generally provide argc and argv. I
think Pd should too. C, C++ has argc, argv Java has args.getLength, String[] args bourne shell has $#, $@ C shell has $#argv, $argv Perl has $#argv, @argvIt could be an object class called [args] too, no? (I don't like the
namebtw, there is an object [dollarg] in iemlib that does exactly this.
$# and $@ would also be useful in messages. But I suppose [arguments]
could handle argc and argv, and be a C object. It could output a list
of the arguments from the left inlet and the number of arguments from
the right inlet.
.hc
¡El pueblo unido jamás será vencido!
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
$# and $@ would also be useful in messages.
For messages, shouldn't people use [list] instead, to achieve the same results?
But I suppose [arguments] could handle argc and argv, and be a C object.
It could output a list of the arguments from the left inlet and the number of arguments from the right inlet.
You can already get the list length using [list length]. No other objects both output a list and a separate float for the length.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 5, 2006, at 5:09 PM, Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
$# and $@ would also be useful in messages.
For messages, shouldn't people use [list] instead, to achieve the same results?
How?
[list $1 $2 ... $99]?
.hc
But I suppose [arguments] could handle argc and argv, and be a C
object. It could output a list of the arguments from the left inlet and the number of arguments from the right inlet.You can already get the list length using [list length]. No other
objects both output a list and a separate float for the length._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
http://at.or.at/hans/
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
On Feb 5, 2006, at 5:09 PM, Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
$# and $@ would also be useful in messages.
For messages, shouldn't people use [list] instead, to achieve the same results?
How? [list $1 $2 ... $99]?
I thought that you meant for accessing a message's argument, in a way consistent with $1 $2 ... $99 already available in messageboxes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi all, although i haven't really followed the thread in detail, i'd like to throw in that there's an external called [absattr] in the grill part of the PD cvs which implements attributes for abstractions. It's another spin-off from vibrez development and i think it's quite useful. There is an example included.
best greetings, Thomas
Am 04.02.2006 um 21:51 schrieb Mathieu Bouchard:
On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
I don't entirely get how it works, looking at the help patch. What are the "attributes"?
Attributes are specific to Flext/Pyext, although GridFlow has a variant on this concept. It's not used in Pd. It's like what's called Keyword Arguments in several languages like Python and CommonLisp, and it's like the dash options in Tcl (though in Tcl it's not a language feature, just a convention).
Is [patcherargs 10 20] like this: [float $1] [float $2]?
I guess so, except that $1 defaults to 10, instead of defaulting to 0, or worse, instead that whenever $1 is 0, it gets replaced by 10...
[patcherargs] seems to allow any number of arguments in the parent patch and so can be used to support varargs abstractions, something that plain Pd can't because you can't even know how many args you really have.
Plus, [patcherargs] gives it as a list, which is then easy to process using [list] (and that's something that Frank will love).
It seems to be a black box, which I am not a fan of. I think we can do it cleaner and do it mostly in Pd.
I'm trying to say that Pd is broken and that [patcherargs] is cleaner...
It wouldn't need to have the "attributes" part available, so you could drop the second outlet and then it would be a very small and simple external whose code fits on a page. Of course I think it should be internal.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Thomas Grill