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

[Chris McCormick]

On Mon, Mar 30, 2009 at 11:28:40AM -0400, Mathieu Bouchard wrote:
> 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

[snip]

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

Ah yes. In this hypothetical dataflow language in my head, whenever you try and
fan cables either in or out, the patcher would automatically turn the fan into
a sort of 'bus' of connections like Pd's [t] object. In other words, in this
language it would not be possible to fan connections. A default behaviour for
incoming fans would be to sum inputs (like DSP fans do now), but this would be
easily configurable to 'replace' instead of 'add' as current message in-fanning
does. Hmm, maybe I haven't thought that through enough.

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

I don't think all the features I'd like in a general purpose dataflow language
can even be added to Pd without serious mangling. For a start I'd like the
basic data types that all modern languages support like associative arrays,
strings, etc. Then I'd like the DSP stuff not to be a special case, but rather
a library you can import. Next I would like it if the graphs were represented
by a data structure that doesn't suck (e.g. an associative array not a
textfile) so that it would be possible to pass the network definition (e.g. the
patch) itself through another network to dynamically create and modify patches.
This new representation of a patch should be serialisable as JSON or similar so
that it's easy to modify by hand and to parse, and to save to disk, or send
across a network. JSON would be nice as it's supported by web frameworks, whcih
means you could do super-cool stuff like websites which read/write/modify/run
patches in your browser, or build patches that use a website to share data
between multiple connected clients. Netpd would be really nice in this new
language. Lastly, it should feature multi-processing out of the box.

Not asking for much, am I? :)

I've thought many times about starting to code this language, and have actually
hesitantly started a couple of times, but very quickly I realise what a massive
undertaking it is and stop. I have too much other work. I guess it would be
possible to build the kernel of the lgnaguage with no GUI quite easily, but the
hard bit would be the 'batteries included'.

Chris.

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