[PD-dev] Proposal for an alternative file format (WAS: pure-data-Feature Requests-3531000)

[Rich E]

Arg, this thread should die, was reposted at the same time. :=)  I'll move
this message there.

On Sat, Jun 2, 2012 at 2:37 PM, Rich E <reakinator at gmail.com> wrote:

>
> (This was on the sourceforge feature requests, I'm taking the liberty to
> move it directly to pd-dev)
>
>
>> Initial Comment:
>> Hi all !
>>
>> With several people from *libpd* and other *pd* offsprings, we have been
>> thinking that it would be great to have an alternative format for pd files
>> (see:
>> http://noisepages.com/groups/pd-everywhere/forum/topic/javascript-json-apis/
>> ).
>> Problem is that the current format is very tedious to parse ; it is very
>> messy (as seen in the complexity of the documentation) ; and last but not
>> least, it doesn't separate the actual graph data from the GUI data (X, Y,
>> canvases, ...). Overall, this is not good for interoperability between
>> different pd/non-pd systems.
>>
>> We were thinking that a simple JSON file would save a lot of trouble :
>> - it has a nested structure, which allows for much clearer, even
>> human-readable format. ex :
>> [
>>    {"class": "obj", "id": 0, "type": "osc~", "args": [440]},
>>    {"class": "obj", "id": 1, "type": "dac~"},
>>    {"class": "connect", "from": [0, 0], "to": [1, 0]},
>>    {"class": "connect", "from": [0, 0], "to": [1, 1]}
>> ]
>>
>> - it allows putting custom attributes (for a GUI for example) :
>> [
>>    {"class": "obj", "id": 0, "type": "osc~", "args": [440],
>>        "myGui": {"x": 123, "y": 78}
>>    }
>> ]
>>
>>
> Strict json has a dictionary as it's outermost object.  Most parsers will
> accept an array as you have done, but not all (Obj-C's TouchJSON as an
> example).  An alternative way to organize the patch and adhere to strict
> json would be to have id's on the outside, such as:
>
> {
> "canvas" :
> {
> "id" : 1,
>  "name" : "example"
> "x" : 95,
> "y" : 190,
>  "width" : 809,
> "height" : 538
> "elements" :
>  {
> "obj" : {"id" : 0, "type": "osc~", "args": [440]},
>  "obj" : {"id" : 1, "type": "dac~"},
> "connect" : {"from": [0, 0], "to": [1, 0]},
>  "connect" : {"from": [0, 0], "to": [1, 1]}
> }
>  "canvas" : { ... }
> "array" : { ... }
> }
> }
>
> About the optional GUI, my opinion is that pd is firstly a graphical data
> flow language existing of canvases and objects with specific location.  To
> make the dimensions optional means interoperability with pd will be
> optional, probably not so good.  If you need extra info, I think that's ok,
> but at a minimum the information in existing pd patches should be
> represented.
>
> You could also pull the GUI locations into a separate object:
>
> {
> "canvas" :
> {
>  "id" : 0,
> "name" : "example"
> "elements" :
>  {
> "obj" : {"id" : 0, "type": "osc~", "args": [440]},
>  "obj" : {"id" : 1, "type": "dac~"},
> "connect" : {"from": [0, 0], "to": [1, 0]},
>  "connect" : {"from": [0, 0], "to": [1, 1]}
> }
>  "layout" :
> {
> "0" : { "pos": [123, 78] },
>  "1" : { "pos": [123, 100] }
> }
> }
>  "layout" :
> {
> "0" : { "pos": [95, 190], "size" : [809, 538] }
>  }
> }
>
> Don't know if it's better or worse, just throwing it out there.  One side
> effect is that the id's here are both in string and int format.
>
>
>
>>
>> ----------------------------------------------------------------------
>>
>> Comment By: Andras Muranyi (muranyia)
>> Date: 2012-06-01 14:00
>>
>> Message:
>> @reakin: when mentioning two files for one patch i was referring to the
>> (nice and convenient) idea of separating logic from presentation by
>> breaking out GUI info into a CSS-like file - which means having two files
>> per patch (not so convenient and nice).
>>
>>
> Ah, understood.  I also think this would be a bit overcomplicated.  If
> it's separated, I think the GUI info could just be under a different object
> in the json of one file.
>
> Cheers,
> Rich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120602/a6c20124/attachment-0001.htm>