On Thu, Mar 26, 2009 at 10:42:25AM -0400, Mathieu Bouchard wrote:
No, this was about how [expr] can be a replacement for even a small
network of objects. If you make an abstraction that does
($f1-$f2)*($f5-$f4)/($f3-$f2)+$f4, with just [+] [-] [*] [/] for example, then if you change some things in the cold inlets, the changes might not
propagate to the bottom. This means you have to add a [pack 0 0 0 0 0] of the whole thing and [unpack 0 0 0 0 0] to ensure every hot-inlet is
retriggered in the proper order. Actually, in this pack/unpack dance,
maybe you can skip the hot-inlet of the abstraction (?), but apart from
that, you're pretty stuck using pack/unpack if you want life to be simple. Else you can weave a mess of [t b f] objects like a spider on caffeine. That's what I mean.
When I was thinking about writing a general purpose dataflow programming language which addresses some of Pd's shortcomings, I did a lot of thinking about the hot and cold inlet paradigm. What I came up with was the following scheme:
Hot inlets are red
Cold inlets are blue
Neutral inlets are grey
A class has a default hot/cold/neutral inlet configuration defined by the author.
The UI allows the user to change the hot/cold/neutral status of inlets.
An instance's 'run' method is executed when any of the following conditions are met:
Inlets cache their last received data if no new data arrives.
In Pd, DSP inlets act like the 'cold' inlets above, message inlets which aren't the leftmost message inlet [usually] act like 'neutral' inlets above, and the leftmost inlet [usually] acts like 'hot' inlets above.
I like the idea of this behaviour being defined by the class author, but (re)configurable by the user.
Best,
Chris.