[PD] Finding "$0" and dealing with it in messages

[Roman Haefeli]

Hi Frank

Thanks a lot for giving me such detailed insight.

Am 26.11.09 09:24 schrieb "Frank Barknecht" unter <fbar at 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