[PD] dealing with arguments and inlets
Hans-Christoph Steiner
hans at eds.org
Sat Feb 4 19:52:41 CET 2006
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 at 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
More information about the Pd-list
mailing list