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

[Mathieu Bouchard]

On Tue, 31 Mar 2009, Chris McCormick wrote:

> Then I'd like the DSP stuff not to be a special case, but rather a 
> library you can import.

It's not much of a feature. It might be a sign of a more modular design, 
but what would actually you do with Pd that'd require DSP to be separated 
like that?

> 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

This makes no sense to me. a JSON serialisation is already a textfile, and 
the .pd file format is already a serialisation of some data structure. 
Actually, that data structure may suck, but it's very replaceable by some 
other structure, but that doesn't affect the file format. I have made a 
version of Pd that replaces linked-lists by something I called t_boxes 
which is defined using a C++ associative array structure:

   struct t_boxes : t_gobj {std::map<int,t_gobj *> map;}

But really, the file format is the same. I had planned a new file format 
but it was 99% compatible with Pd. I don't believe that we'd have to 
switch to JSON just before it's newer.

If you're complaining about the format of the IEMGUI constructors, that's 
a different problem. This is not part of the .pd format by itself: it's a 
subformat. You can abuse another format in the same way, be it JSON, XML, 
YAML, LISP data, TCL data, other text formats, binary formats.

The way that IEMGUIs are saved could be fixed without having to change the 
Pd format, really. It just needs a bit of imagination. And then, the only 
code you'd need to change would be the code of IEMGUIs, just as if they 
were still externals. For example, IEMGUIs could save themselves using 
Flext-like attributes or GridFlow-like comma-messages, which are two 
styles of named-arguments in use in Pd (the latter is actually more like a 
[initbang] with a messagebox).

> so that it's easy to modify by hand and to parse, and to save to disk, 
> or send across a network.

Well, you'd have to explain how JSON is going to be any easier to modify, 
parse, save and send, because I don't see it. Especially because when you 
say JSON, there's nothing that tells me exactly how JSON is going to be 
used for that. In any case, the differences between the many ways that you 
can use JSON for that, parallel the differences between the many ways Pd's 
syntax could be used.

> JSON would be nice as it's supported by web frameworks, whcih means you 
> could do super-cool stuff like websites

Maybe it's just me... I'm not especially web-centric... well, I use the 
web a lot, but haven't done any serious web development in this 
millenium... so far.

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

Well, every person has their favourite way or dream way to encode data, 
but it doesn't mean it's enough of a reason to redo things. When I thought 
about all those things about format modifications I considered that it's 
easier to go "in the direction of the grain", that is, to use the same 
parser that is already used all over Pd, and if that's not enough, that 
it's still better to make a format 99%-compatible with Pd than 0%.

> I have too much other work.

It's also that even if it were not too much work or if you didn't have too 
much other work, if you build yourself a small island of software, you are 
pretty much alone. You need as many forms of compatibility as you can. 
There are several other visual dataflow programming languages that haven't 
really taken off because presumably there are not enough plugins for them 
and such... a not-so-well-designed programme that is very much used ends 
up being much more useful than a lonely programme.

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

I have no idea what part of the programme is the batteries supposed to 
represent.

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