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