> This issue would also appear if we forced stream transducers (processing nodes) to output a fixed number of value at each invocation: it suffices to let S rep

> This issue would also appear if we forced stream transducers (processing nodes) to output a fixed number of value at each invocation: it suffices to let S repeat each value of X twice, i.e., interleave X with X. I don't understand how the issue would appear in that case. Buffering one value seems to be sufficient to upsample S to the "clock" of X, ie. project S to the instants where X is defined (flow Z below) while filling missing instants with the previously known value: X : X0 X1 X2 X3 ... S : S0 S1 Z : S0 S0 S1 S1 That would look as follows in Signal: process test = (? integer x ! integer y) (| c := not (c$ init false) | s := (x when c) cell c | y := x + s |) where boolean c; integer s; end; C is the clock which alternates between false and true ($ refers to the last value), "X when C" is filtering, "E cell C" is projection of values of E to the instant of C, defaulting to the previous known value at logical instants where E is not present but C is true. The clock calculus in Signal (etc.) is way to assess if a program can be generated to use constant (static) memory allocation and constant time. There are programs which fail to do so, but you then need to refine them to add explicit operations (https://www.irisa.fr/prive/talpin/papers/date08.pdf https://www.irisa.fr/prive/talpin/papers/date08.pdf)