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 <reakina...@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 >
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev