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