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