#113 Proposal for an alternative file format

open
nobody
None
5
2012-05-31
2012-05-31
No

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}
}
]

- icing on the cake, there's good JSON libraries in every language... so no need to write custom parsers, and it would be straightforward to implement APIs (for example for some dynamic patching) based on that format.

Of course, for a start, there would need to be support for both file formats. But I am volunteering to write a converter .pd <-> .json as a small standalone tool.

So ... would this interest any of you !?

Sébastien

Discussion

  • Andras Muranyi
    Andras Muranyi
    2012-05-31

    > it doesn't separate the actual graph data from the GUI data

    Interesting.
    What about using a separate, CSS-like syntax for GUI data, rather than the inline format in the example (myGui": {"x": 123, "y": 78})?

     
  • My point was to specify a core format which doesn't include any specification about GUI stuff. So then, GUIs are free to add the info they need to the project ! Whether it is css, or whatever else is not really the question here.

    That said, this sounds like a good idea, depending on what you use to render the interface. If you have to write a css parser, or use one, just to position elements, it sounds a bit complicated to me.

     
  • Andras Muranyi
    Andras Muranyi
    2012-06-01

    Well, CSS is more or less JSON. I'm sure it can be parsed with a JSON parser. My idea is just to split out formatting info from the main file... which may or may not be convenient. Now that I think about having two files for each patch, it seems actually less convenient :)

     
  • Rich E
    Rich E
    2012-06-01

    @muranyia you don't have to have 2 files for each patch, the proposal is for a new, easier to read / parse, format for existing patches. This facilities writing 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. You could still ignore this extension completely, and maybe with time we will be able to directly read a patch that is in .json, thereby ignoring the already existing format - that would be after some refactoring to pd internals, which is not part of this proposal.

    I think JSON is much easier to parse than CSS for the wide variety of programming languages we are addressing - yes they are similar, but CSS is not valid JSON.

    @muranyia will you write a .json -> .pd converter too? With both, we can test using it in existing libpd applications in order to further tell what the best API would look like.

    It would be great to hear the input of some other pd veterans, if they've ever envisioned an alternate patch format and what it would look like.

     
  • Rich E
    Rich E
    2012-06-01

    Darn, can't edit here. The second @comment in my last comment was directed at
    Sébastien (the creator of the thread). I also think this should be moved to one of the mailing lists, either pd-dev or pd-list.

     
  • Andras Muranyi
    Andras Muranyi
    2012-06-01

    @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). BTW, the "GUI data file" doesn't have to be CSS just "something like CSS" so it could be valid JSON. But at the end, I agree with all that 'nobody' said (2012-06-01 05:12:15)

    So, let's move the conversation to pd-dev.

     
  • I read this publish as well as totally believe Anyone. Your current reveal is fantastic and I will certainly reveal the idea together with my buddies and also facebook or myspace contacts. If i a web site in your niche Id will give you a link exchang
    <a href="http://colorfield5.blogoak.com?blogname=colorfield5&postarch=5" title="Keep Guide">Keep Guide</a>

     
  • Valuable data and excellent design you still have here! I would want to thank anyone for sharing your thoughts and time in to the stuff anyone post!! Thumbs way up!
    <a href="http://canon-mcmillan.patch.com/events/increase-the-amount-of-spruce-on-your-apple-ipad-with-classy-apple-ipad-templates" title="Ipad">Ipad</a>

     
  • Hello, hows it going? Just shared this post with a colleague, we had a good laugh.
    <a href="http://www.glogster.com/birthrabbi88/myglogster" title="In which">In which</a>

     
  • Thanks for some other informative web site. The place else could I am getting that kind of information written in such a perfect way? I have a project that I'm just now working on, and I have been on the glance out for such information. [url=http://miumiuoutlet.v5s7.com]Miu Miu Bags[/url]

     


Anonymous


Cancel   Add attachments