Message: 8 Date: Mon, 30 Jan 2006 19:03:09 -0500 From: Hans-Christoph Steiner hans@eds.org Subject: [PD] dealing with arguments and inlets To: PD-List List pd-list@iem.at Message-ID:
f800a0b7f1f7e6ccf418411ac1afacee@eds.org
Content-Type: text/plain; charset="us-ascii"
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?
This is a very cool idea. Virtually all my abstractions have an inlet and ii (from iem) for each argument: would definitely be better to have both in one.
Might it be better to go all the way and have these as externals which function as [inlet], but also support defaults as you've said? Obviously then it would be cool to keep the naming argument of [inlet], which appears when you hover.
Or alternatively to extend the built-in inlet to give the functionality you've said, while just behaving as currently if the extra arguments aren't given, e.g.:
[inlet] - as current [inlet name] - as current, with a name [inlet name $1] - as current, but at loadbang-time output $1 [inlet name $1 123] - as current, but at loadbang-time output $1, or 123 if $1 not specified
Don't know how you'd handle the separation of floats, symbols and anys then though...maybe add finlet and sinlet...??
Cheers Stefan Turner
Yahoo! Photos  NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com
Hallo, Stefan Turner hat gesagt: // Stefan Turner wrote:
This is a very cool idea. Virtually all my abstractions have an inlet and ii (from iem) for each argument: would definitely be better to have both in one.
Not for me. ;)
I tend to see inlets and arguments as serving a different purpose. Instead of using lots of inlets my abstractions generally use only on or two inlets and internally [route] messages according to selectors.
I would do so even with inlet tooltips or similar helpers, as I find it much more conventient to provide lots of selector-messages but only have a small amount of inlets in my abstractions, because I hate having to find the right inlet to connect to. For abstraction arguments it's slightly different as these are just input once, on object creation. Although I like to even get rid of using too many arguments and instead just use one argument which internally gets transformed into a receiver that is connected to the same [route] as the inlet is. (So maybe inlets and arguments serve the same purpose after all?) Initialization then happens somewhere else (like in a [pool] in Memento).
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jan 31, 2006, at 6:34 PM, Frank Barknecht wrote:
Hallo, Stefan Turner hat gesagt: // Stefan Turner wrote:
This is a very cool idea. Virtually all my abstractions have an inlet and ii (from iem) for each argument: would definitely be better to have both in one.
Not for me. ;)
I tend to see inlets and arguments as serving a different purpose. Instead of using lots of inlets my abstractions generally use only on or two inlets and internally [route] messages according to selectors.
I would do so even with inlet tooltips or similar helpers, as I find it much more conventient to provide lots of selector-messages but only have a small amount of inlets in my abstractions, because I hate having to find the right inlet to connect to. For abstraction arguments it's slightly different as these are just input once, on object creation. Although I like to even get rid of using too many arguments and instead just use one argument which internally gets transformed into a receiver that is connected to the same [route] as the inlet is. (So maybe inlets and arguments serve the same purpose after all?) Initialization then happens somewhere else (like in a [pool] in Memento).
The way I have been thinking is that the first inlet is the general
inlet, and it can accept many types of messages. Then the second inlet
lines up with the first argument, the third inlet to the second
argument, etc. I think this is pretty clean and flexible, and I think
it would be nice to have some kind of standard for this.
Obviously, it doesn't work for all objects, but I think it would be
good to standardize on objects it does work for.
.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:
The way I have been thinking is that the first inlet is the general
inlet, and it can accept many types of messages. Then the second inlet
lines up with the first argument, the third inlet to the second
argument, etc. I think this is pretty clean and flexible, and I think
it would be nice to have some kind of standard for this.Obviously, it doesn't work for all objects, but I think it would be
good to standardize on objects it does work for.
The RRADical patches would be an example for an orthogonal (rradically different) approach. Here the first argument is a "tag", which generally can not be changed except by reinstantiating the abstraction, but not through an inlet (there are ways to change it internally, but this, too, works different).
The rightmost in- and outlets are catch-all inlets intended for list-like OSC-messages. The targets are actually automatically built depending on what kind of [commun] objects are used inside the abstraction.
Explaining this in words might seem complicated, but once you use it, it feels very natural. On one hand it saves a lot of work and on the other it offers a bigger flexibility than mapping inlets and arguments one-to-one. (You could think of the OSC-inlets as a kind of macro.)
For example I can add a new "thing" to set remotely just by creating a [commun /thing $0] object inside an abstraction. Nothing more and no inlets are necessary to make this "/thing" read- and settable through the OSC-in/outlet.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The way I have been thinking is that the first inlet is the general
inlet, and it can accept many types of messages. Then the second inlet
lines up with the first argument, the third inlet to the second
argument, etc. I think this is pretty clean and flexible, and I think
it would be nice to have some kind of standard for this.
...
For example I can add a new "thing" to set remotely just by creating a [commun /thing $0] object inside an abstraction. Nothing more and no inlets are necessary to make this "/thing" read- and settable through the OSC-in/outlet.
I just counted (with the help of "wc") how many [commun]'s are used in rrad.pattseq.pd, the most complex RRADdical patch, and there are exactly 80. It would require 80 arguments and 80 inlets to provide the same functionality in a traditional way, that RRADical provides using one inlet and one argument.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Feb 4, 2006, at 11:53 PM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The way I have been thinking is that the first inlet is the general inlet, and it can accept many types of messages. Then the second
inlet lines up with the first argument, the third inlet to the second argument, etc. I think this is pretty clean and flexible, and I
think it would be nice to have some kind of standard for this....
For example I can add a new "thing" to set remotely just by creating a [commun /thing $0] object inside an abstraction. Nothing more and no inlets are necessary to make this "/thing" read- and settable through the OSC-in/outlet.
I just counted (with the help of "wc") how many [commun]'s are used in rrad.pattseq.pd, the most complex RRADdical patch, and there are exactly 80. It would require 80 arguments and 80 inlets to provide the same functionality in a traditional way, that RRADical provides using one inlet and one argument.
Obviously this inlet/argument standard wouldn't work for that, and I am
not suggesting that it should be used everywhere. I am suggesting that
when you use inlet/argument pairs, they should follow that standard.
And I think inlet/argument pairs should be used whenever possible.
.hc
¡El pueblo unido jamás será vencido!
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
The way I have been thinking is that the first inlet is the general inlet, and it can accept many types of messages. Then the second inlet lines up with the first argument, the third inlet to the second argument, etc.
I agree. Many objects obey the rule that the k'th inlet matches argument $k for several arguments in a row, usually all of them.
I think this is pretty clean and flexible, and I think it would be nice to have some kind of standard for this.
And the best way to make sure people are following a standard is to make it so easy to follow that it's harder to not follow it than to follow it. Of course I don't mean adding hurdles to doing it otherwise, but rather make a shortcut for those who follow the standard. Short of this, people who make abstractions/externals can get a friendly reminder, from someone who cares, that it would be better if they followed the standard.
Obviously, it doesn't work for all objects, but I think it would be good to standardize on objects it does work for.
PureUnity's goal (when I work on it) is to design a taxonomy that separates objects that obey certain properties, from those that don't, because that's a way to reuse tests, but also because certainly it doesn't hurt documentation either, and it's even better if it can influence how abstractions are made.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 31, 2006, at 2:02 PM, Stefan Turner wrote:
Message: 8 Date: Mon, 30 Jan 2006 19:03:09 -0500 From: Hans-Christoph Steiner hans@eds.org Subject: [PD] dealing with arguments and inlets To: PD-List List pd-list@iem.at Message-ID:
f800a0b7f1f7e6ccf418411ac1afacee@eds.org
Content-Type: text/plain; charset="us-ascii"
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?
This is a very cool idea. Virtually all my abstractions have an inlet and ii (from iem) for each argument: would definitely be better to have both in one.
Might it be better to go all the way and have these as externals which function as [inlet], but also support defaults as you've said? Obviously then it would be cool to keep the naming argument of [inlet], which appears when you hover.
Or alternatively to extend the built-in inlet to give the functionality you've said, while just behaving as currently if the extra arguments aren't given, e.g.:
[inlet] - as current [inlet name] - as current, with a name [inlet name $1] - as current, but at loadbang-time output $1 [inlet name $1 123] - as current, but at loadbang-time output $1, or 123 if $1 not specified
Don't know how you'd handle the separation of floats, symbols and anys then though...maybe add finlet and sinlet...??
I like keeping them separate because that means it can be written in
Pd, and the C objects are just the most primitive, like plain old
[inlet]. Plus you can use them separately, since inlets and arguments
are not one in the same...
.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.
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Stefan Turner