So, ... moving the discussion here from sourceforge's tracker :
@Sébastien will you write a .json -> .pd converter too?
Rich, notice the double arrow ".json <-> .pd" ;)
the proposal is for a new, easier to read / parse, format for existing
patches. This facilities writing/reading patches in other languages (such as javascript, C / C++ / Obj-C / Java, etc.), since you wouldn't need to write the text file in a cryptic form.
Yes, exactly ... well said !
Like Rich said also, it would be good to have input from some pd veterans. For one thing, just to get feedback and comments, but also to know if it has any chances to be implemented one day in pure data. Indeed, right now the file format is THE bridge between pd, libpd, webpd and others ... so if some of the libraries implement this format and not others, it might end up just putting mess and fragmenting the pd world. So ... waiting an answer from pd-devs on whether or not this might be implemented :) ! And what about libpd devs ?
On 06/02/2012 07:50 PM, s p wrote:
So, ... moving the discussion here from sourceforge's tracker :
@Sébastien will you write a .json -> .pd converter too?
Rich, notice the double arrow ".json<-> .pd" ;)
the proposal is for a new, easier to read / parse, format for existing
patches. This facilities writing/reading patches in other languages (such as javascript, C / C++ / Obj-C / Java, etc.), since you wouldn't need to write the text file in a cryptic form.
I am certainly not a pd-veteran but I think this is a *very good* idea.
y
(from Sébastien:)
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
On Sat, Jun 2, 2012 at 2:01 PM, yvan volochine yvan.pd@gmail.com wrote:
On 06/02/2012 07:50 PM, s p wrote:
So, ... moving the discussion here from sourceforge's tracker :
@Sébastien will you write a .json -> .pd converter too?
Rich, notice the double arrow ".json<-> .pd" ;)
the proposal is for a new, easier to read / parse, format for existing
patches. This facilities writing/reading patches in other languages (such as javascript, C / C++ / Obj-C / Java, etc.), since you wouldn't need to write the text file in a cryptic form.
I am certainly not a pd-veteran but I think this is a *very good* idea.
y
-- http://yvanvolochine.com http://vimeo.com/yv http://soundcloud.com/**yvanvolochinehttp://soundcloud.com/yvanvolochine
______________________________**_________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/**listinfo/pd-devhttp://lists.puredata.info/listinfo/pd-dev
Strict json has a dictionary as it's outermost object.
I don't think this is true. I was not sure so I checked the spec : http://www.ietf.org/rfc/rfc4627.txt?number=4627 and apparently a valid json string is either an array or an object.
Most parsers will accept an array as you have done, but not all (Obj-C's TouchJSON as an example)
TouchJSON's says (https://github.com/TouchCode/TouchJSON#invalid-json) : "If you think your JSON is valid but TouchJSON is failing to process it correctly, use the online JSON lint tool to validate your JSON:http://www.jsonlint.com/ "
And it turns out, jsonlint accepts json with an array as outermost element. Personally, I've always used an array, and many API libraries that I am using for web development return an array as outermost element.
About the optional GUI, my opinion is that pd is firstly a graphical data flow language existing of canvases and objects with specific location.
Once again (sorry :) I disagree ... True, "pd is firstly a graphical data flow language". However, times they are a changing, and libpd is becoming more and more important, and will probably continue to grow. Also, I might be wrong, but I am guessing nobody would disagree that it is a good idea to go towards a better separation between pd core and its GUI. When you specify something new, it is a good occasion to do things well and clean. Passing over some legacy stuff to a new specification you are writing kind of kills the purpose of making a new specification.
For all those reasons, I think it is a good idea to specify a minimalist file format that doesn't include GUI infos. Of course, it should include special placeholders for putting extra info (where GUI info can be put). And as a new parser will have to be written anyways, it is not much extra-work to handle missing attributes that are not mandatory in the spec.
For example, if I take the example I had given before :
*[** {"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]}**]*
// start parsing, in pseudo-code foreach element in element_list { if (element.class is "obj") { obj = create_new_obj_with_type_and_args(element) if (has_display_infos(element)) { set_object_display(obj, element) } else { set_default_display(obj) } } // ... }
what I mean is that the core specified should be small : objects, connections, data ; and if a particular program (pd, libpd, ...) using this format wants to add extra-info, it should handle the case where those infos are not available when parsing. Or at least, that's my opinion :)
Question: do you care about backwards compatibility, or is it a non-issue?
-Jonathan
From: s p sebpiq@gmail.com To: pd-dev@iem.at Sent: Sunday, June 3, 2012 9:33 AM Subject: Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
Strict json has a dictionary as it's outermost object.
I don't think this is true. I was not sure so I checked the spec : http://www.ietf.org/rfc/rfc4627.txt?number=4627 and apparently a valid json string is either an array or an object.
Most parsers will accept an array as you have done, but not all (Obj-C's TouchJSON as an example)
TouchJSON's says (https://github.com/TouchCode/TouchJSON#invalid-json) : "If you think your JSON is valid but TouchJSON is failing to process it correctly, use the online JSON lint tool to validate your JSON:
And it turns out, jsonlint accepts json with an array as outermost element. Personally, I've always used an array, and many API libraries that I am using for web development return an array as outermost element.
About the optional GUI, my opinion is that pd is firstly a graphical data flow language existing of canvases and objects with specific location.
Once again (sorry :) I disagree ... True, "pd is firstly a graphical data flow language". However, times they are a changing, and libpd is becoming more and more important, and will probably continue to grow. Also, I might be wrong, but I am guessing nobody would disagree that it is a good idea to go towards a better separation between pd core and its GUI. When you specify something new, it is a good occasion to do things well and clean. Passing over some legacy stuff to a new specification you are writing kind of kills the purpose of making a new specification.
For all those reasons, I think it is a good idea to specify a minimalist file format that doesn't include GUI infos. Of course, it should include special placeholders for putting extra info (where GUI info can be put). And as a new parser will have to be written anyways, it is not much extra-work to handle missing attributes that are not mandatory in the spec.
For example, if I take the example I had given before :
[ {"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]} ]
// start parsing, in pseudo-code foreach element in element_list { if (element.class is "obj") { obj = create_new_obj_with_type_and_args(element) if (has_display_infos(element)) { set_object_display(obj, element) } else { set_default_display(obj) } } // ... }
what I mean is that the core specified should be small : objects, connections, data ; and if a particular program (pd, libpd, ...) using this format wants to add extra-info, it should handle the case where those infos are not available when parsing. Or at least, that's my opinion :)
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sun, Jun 3, 2012 at 9:33 AM, s p sebpiq@gmail.com wrote:
Strict json has a dictionary as it's outermost object.
I don't think this is true. I was not sure so I checked the spec : http://www.ietf.org/rfc/rfc4627.txt?number=4627
and apparently a valid json string is either an array or an object.
Most parsers will accept an array as you have done, but not all (Obj-C's TouchJSON as an example)
TouchJSON's says (https://github.com/TouchCode/TouchJSON#invalid-json) :
"If you think your JSON is valid but TouchJSON is failing to process it correctly, use the online JSON lint tool to validate your JSON:http://www.jsonlint.com/ "
And it turns out, jsonlint accepts json with an array as outermost element. Personally, I've always used an array, and many API libraries that I am using for web development return an array as outermost element.
I stand corrected. I remember having difficulties using TouchJSON and receiving json with an array as outermost element, but this was a while back and it's clearly supported when I look at it now. To me, it still seems vague this way: what _is_ the array? Is it a patch? A canvas? A file? When you use a dictionary, the name of the key is helpful in clearing this up. It can also simplify parsing order.
About the optional GUI, my opinion is that pd is firstly a graphical data flow language existing of canvases and objects with specific location.
Once again (sorry :) I disagree ... True, "pd is firstly a graphical data flow language".
However, times they are a changing, and libpd is becoming more and more important, and will probably continue to grow. Also, I might be wrong, but I am guessing nobody would disagree that it is a good idea to go towards a better separation between pd core and its GUI.
When you specify something new, it is a good occasion to do things well and clean. Passing over some legacy stuff to a new specification you are writing kind of kills the purpose of making a new specification.
For all those reasons, I think it is a good idea to specify a minimalist file format that doesn't include GUI infos.
Of course, it should include special placeholders for putting extra info (where GUI info can be put). And as a new parser will have to be written anyways, it is not much extra-work to handle missing attributes that are not mandatory in the spec.
I agree with you that graphical representation should be separated out and
it should be possible to be auto-generated if not present, but I think it deserves a classification higher than 'extra info'. A formal extension of the format, so to speak, since the majority of use cases involving a pd patch will require a visual layout. If you let every app define it's own format for graphical layout, there will be no interchange. For example, you can define an optional key such as "layout" that contains well known child nodes like "x", "y", "size", etc. If an element has this, great, if not, an app can generate this data. But at least the parsing will be well known across the possibly many different graphical interfaces.
Cheers, Rich
-
Jonathan Wilkes -
Rich E -
s p -
yvan volochine