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

Mathieu Bouchard matju at artengine.ca
Mon Apr 6 20:06:25 CEST 2009


On Mon, 6 Apr 2009, Chris McCormick wrote:

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

Ok, you know what playing nice means and what human readable means, I 
can't help you with that at all. I didn't watch the infomercials about 
JSON, so I don't know how amazingly easier than everything else it is.

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

After the parser is ready, you still have to write the programme that will 
actually do something useful with the patch that has been read and parsed, 
and that will most likely the part of the work that will be the most 
significant, especially if you don't bother about handling backslashed 
spaces properly, because pd doesn't anyway.

If you already have a [netreceive] in the target language, you already 
have a parser for much of the pd format...

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

So why would those people who don't care about Pd's syntax would ever care 
about processing Pd patches? It just doesn't make any sense.

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

I don't think any interoperability is going to be gained from using a 
JSON-based format (that you still haven't specified) because no non-Pd 
people will want to process patches. Forget everything about the format 
being readable by real human beings (by opposition to those damn pd 
users), a JSON-based patch format will only achieve one thing, allow the 
JSON fans to say that Pd supports JSON.

> Yes, that's very true. I guess with the idea of a very social format 
> like YAML or JSON

Once you consider the actual number of XML/YAML/JSON users who would be 
processing any pd patch if it were coded in their favourite encoding, then 
you wouldn't feel nearly as lonely with the Pd format, really. I'm 
expecting you to be disappointed by what JSON will bring to Pd.

In any case, it's still easy to make a Pd-to-JSON converter, so, invent 
yourself a suitable JSON-subformat for converting your Pd patches to, and 
see whether any JSON user cares, and it will save us having to convert all 
of our patches to JSON, really.

> I am trying to advocate a language that interoperates nicely and easily 
> with other languages and hence isn't a small island of software

Be careful of all of the "details" of the software, which is everything 
else that isn't already covered by JSON, which is almost everything of 
what makes a patch a patch and what makes pd pd (or what makes some other 
patching system be what it is). The superficial part of the syntax is 
superficial but it's easy to exaggerate it at the expense of all of the 
depth of the syntax.

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


More information about the Pd-list mailing list