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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
