Re: [PD-dev] Proposal for an alternative file format (WAS: pure-data-Feature Requests-3531000)
(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
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@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
-
Rich E