[PD] Re: [PD-announce] k_cext V0.2.4 -- about trigger

[IOhannes m zmoelnig]

hi.

funny idea, but i think it's great (although not having tested it yet)

BUT:::

> THE SAME EXAMPLE AS A PD SUB-PATCH
> 
> 
>         The following PD-patch does the same:
> 
>         [inlet]
>         |
>         +-------+
>         |       |
>         [bang]  |
>         |       |
>         [ float ]
>         |
>         [outlet]
> 
>         You must also make sure that the inlet->bang connection
>         is made before the inlet->float connection.
> 
and here comes::

>         I guess its a matter of personal taste, but I really don't
>         find the PD-way of sending out a previous value very intuitive.
>         And especially not the requirement to create the connections in
>         a certain order to make a patch function correctly.

i don't want to be rude or so, but i really think, that you don't have 
fully understood the way, pd handles orderings.

to rely on "creating the connections in a certain order" is plain nonsense.
i always thought, that it is highly discouraged to rely on the order of 
creating objects, to do so is considered a bug, and that the behavious 
might change in future releases (i really think i have read this 
somewhere, but of course maybe that was just how i "learned" pd at 
university...).
ah i have found the line in 2.control.examples/03.connections.pd:
"If an outlet is connected to more than one inlet it's undefined which 
inlet will get the cookie first."
note the *undefined* !!

however: pd is a graphical programming language with one simple paradigma:
if you have the plot/image of a pd-patch and you make a patch, that 
looks exactly the same, the patch *has* to work exactly the same way.
this of course is not true if you rely on the order of cord-creation.
(note: it is also not quite true if you are using all those features of 
the gui-objects (hslider and friends), because they hide their states.)
therefore, there is an object [trigger] (or simply [t]) which provides a 
clean solution for this problem.

the solution to the "latch"-problem (get the previous entry) will thus 
look like


[inlet]
|
[t f b]
  \ /
   X
  / \
[f]
|
[outlet]

please do not keep telling people, that in pd it is important to create 
cords in a certain order to make a patch work correctly.
please tell people, to read the documentation (at *least* the 
control-examples)

nevertheless, i think k_cext sounds cool

mfg.as.erd
IOhannes