[Gridflow-dev] ping (fwd)

[Tom Schouten]

> 
> Well, I don't know that one object is supposed to count as a "systolic
> array". Reading the article I get the impression that you have to connect
> a bunch of them together, e.g. each left-outlet connected to the
> left-inlet of the object below, and each right-outlet connected to the
> right-inlet of the object to the left. Different topologies have different
> patterns of connection for sure, but here i say it's not the same, maybe
> i'd call it a "knot" in the flow, whereby one object is involved twice
> during _one_ chain of processings, distinguishing between the two by using
> two different inlets, and the second involvement completes the task begun
> in the first. Just a way of "passing objects as arguments to other
> objects" in Pd. I haven't seen anyone else use such a pattern in Pd
> though.
> 

martin pi mentioned this idea to me a while ago and i think thomas grill 
is working on something similar to that, but i have only faint recollection 
of details.

i still can't step away from the systolic array concept. what you suggest
seems indeed more general.

about the knot in the control flow. i'm still trying to figure out what
could be gained by this. could you give a practical example of that?

it seems to me the idea to be captured is code to be sent over the wires
in addition to data.


i had a very short discussing with cgc about pd's singlethreadedness.
and it's strange that we had an almost orthogonal view on things.

i think this is one of the most elegant parts of pd. most seem to regard
it as a bug, but it simply avoids all problems with synchronization
by being explicitly serial, but looking like dataflow. it avoids feedback
loops the way any state machine would do this: using a register. no
hidden magic. i'm going to shoot anyone who tries to change that :)

but still, i'm interested in why exactly you would sacrifice this simplictly.
what exactly can be gained, what can be done in a more convenient way
to justify this added complexity?