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.
Well ... this just cosmetics ... I think the array is very flexible, in that you can just stuff objects in there. And, there will be arrays anyways. What you suggested is actually not possible :
{ "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]} } }
In a map, keys need to be unique. So, you would need to write :
{ "elements" : { "obj" : [ {"id" : 0, "type": "osc~", "args": [440]}, {"id" : 1, "type": "dac~"}, ], "connect" : [ {"from": [0, 0], "to": [1, 0]}, {"from": [0, 0], "to": [1, 1]} ] } }
Which imo, is not much better than :
[ {"class": "object", "id" : 0, "type": "osc~", "args": [440]}, {"class": "object", "id" : 1, "type": "dac~"}, {"class": "connect", "from": [0, 0], "to": [1, 0]}, {"class": "canvas", ...}, ]
in that there is less nesting, it is thus a bit simpler... but I guess that's a detail.
It can also simplify parsing order
That's true ...
I think [GUI info] 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.
That's a very good point, ... it's a good idea to specify GUI infos, for better interoperability, but it should be explicitly said that this is optional information, and parsers must handle the case when those are missing.
@Jonathan : Yes, backward compatibility is mandatory, in that the new format must be a subset of the old format - I mean, "semantical" subset : it must be able to contain all the infos contained in old file format And we suggested to write a converter to help this.