[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