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

[Frank Barknecht]

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. 

> 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. Or said in another way: You can
select what behaviour you want an object to show by prefixing your messages
with a certain "selector" - this is where the word "selector" comes from. For
example a [delay] object has these behaviour methods on the first inlet:

a) send a bang after the time of its stored delay time
b) set the stored delay time to x and send a bang after that time
c) cancel any scheduled bangs

You select behaviour a) by sending a "bang" message, you select b) by messages
with selector "float" and c) with selector "stop".

On the C-code side, this is handled with messages like delay_bang(),
delay_float(), delay_stop() that get called according to the selector. If you
write an abstraction, you can mimick the same things with [route float bang
stop]. You've all done this already.

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. But these inconsistencies are not caused by the message mechanism
behind it, they are caused by the object's author, either deliberatly or not.

> 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. :)

> Thinking of the the [symbol] vs. [symbol\ and the [route] example (you
> mention below), one is just left with trying out the different cases and
> remember them.

Or thinking about making a bug report/feature wish. 
 
Ciao
-- 
Frank