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.