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

[Chris McCormick]

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.

-------------------
http://mccormick.cx