[PD] [OT] Re: DIY GSoC: getting those projects done
reakinator at gmail.com
Thu Apr 9 18:51:00 CEST 2009
On Mon, Apr 6, 2009 at 8:06 PM, Mathieu Bouchard <matju at artengine.ca> wrote:
> 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.
I sometimes would like to write a part of a patch in python, like say
all the audio files in one directory, each in a seperate array, and
then load it in pd. This can be done completely in pd, but for
reasons I don't yet understand (other than it is quite easy to crash
pd when dynamic patching), it is not widely supported.
Writing this patch in python with the current format would just be
messy. Doing it in JSON or YAML would be straightforward.
Maybe, as more of a proof of concept, a JSON->pd format file converter
can be made?
>> 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?
>> 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
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list