[PD] [OT] Re: DIY GSoC: getting those projects done

[Chris McCormick]

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:
	* Every cold inlet has been pinged (receives data)
	* Any hot inlet has been pinged (receives data)
* 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.

-------------------
http://mccormick.cx