On Tue, Mar 31, 2009 at 10:27:07PM -0400, Mathieu Bouchard wrote:
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?
Maybe similar things to what you can do with pipes on the unix command line. Except times ten.
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;}
Way cool.
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).
No, that's not at all the reason I think that a format like JSON or YAML would be useful. It's more to do with patches being more widely and easily parseable, mashable, etc. It's to do with interoperating with more programs than just Pd itself. Sure, we could do this and that, and we could use 'a bit of imagination' but the current format of Pd patches is not friendly or popular. I'd rather have a patch format that plays nice with other programs and is easily human readable.
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.
How many parsers are there which read Pd patches? One mainly, maybe other obscure ones which I don't know about, and some that I have written which nobody knows about. How many parsers are there for the JSON format? Hundreds, in hundreds of different languages.
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.
Yep, I get what you are saying, but you are unfortunately wrong. Nobody cares about Pd's syntax except our small band of merry Pd people. Even your point about not knowing how JSON (or YAML or whatever) is going to be used is irrelevant because of the gain in interoperability with other programs and people. The details of how Pd patches are represented in a new format are not as important as the idea of using a popular, human friendly, and widely parseable format to represent them.
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'm very conservative when it comes to web2.0 and that kind of hype, but I am a big fan of standards and interoperability.
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%.
It's a good point, but I don't think I'd bother making a new language compatible with Pd because it wouldn't be trying to do the same thing as Pd is used for.
As for not redo-ing things, you are right that it should be a very strong reason to start something from scratch versus using existing code.
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.
Yes, that's very true. I guess with the idea of a very social format like YAML or JSON I am trying to advocate a language that interoperates nicely and easily with other languages and hence isn't a small island of software, but rather a part of the archipelago with a fancy port which many ships like to dock at. Whoa, that's a bit of a metaphor stretch, sorry.
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.
Libraries.
Best,
Chris.