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

Mathieu Bouchard matju at artengine.ca
Mon Mar 30 17:28:40 CEST 2009


On Sat, 28 Mar 2009, Chris McCormick wrote:

> 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

Well, it would be cool to have a way to configure that in Pd using a 
uniform syntax all over Pd, or using Pd's GUI. Even without that, I think 
that it would be important to introduce the "run" concept anyway, because 
it could help structuring the documentation; I mean it could be introduced 
at the documentation level first. For implementation, it's currently 
harder, especially in GridFlow where the implementation currently uses the 
hot/cold asymmetry to optimise.

> * 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

Well, perhaps you should rename 'neutral' inlets to 'cold' and find 
another name for what you call 'cold'. Even then, DSP inlets still don't 
work like your 'cold' inlets because of how they combine together a fan-in 
(several wires to one inlet) and because of how they handle a 
non-connected inlet.

> I like the idea of this behaviour being defined by the class author, but
> (re)configurable by the user.

Then this would need a special 'run' method to be defined in t_class, 
preferably outside of the normal method-list. At first thought I think I'm 
in favour of reconfigurable inlets, but I'd like to see a proof-of-concept 
first.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
5B


More information about the Pd-list mailing list