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