[PD] [OT] Re: DIY GSoC: getting those projects done
Chris McCormick
chris at mccormick.cx
Tue Mar 31 19:22:51 CEST 2009
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
More information about the Pd-list
mailing list