On Fri, May 18, 2012 at 4:55 PM, João Pais <jmmmpais-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:

Thanks for the report!
I've uploaded a quick bugfix to adapt to the new menu structure: there is
no Media->Preferences (or Apple->Preferences) any more, so the plugin will
appear in Media (or Apple).

Please note that this version still uses the deprecated method of disabling
plugins by putting them in subdirectories called "disabled". This means
that new subdirectories called "disabled" will be created where file
permissions are sufficient. It will affect every user on the system.
A new version shall make use of the "::pd_guiprefs" system instead. I'll
try to give it a shot today or in the next days.

so you mean, it pays up to wait for it, then? I'm new to 0.43, and I put the plugins in a folder in my electronic section, away from windows' standard system/user folders.

João

Well i guess it doesn't pay up to wait anymore :)
The pd_guiprefs mechanism is a tiny bit less handy than I expected so this will still take some more time for me.
In the meantime I suggest that you get the oldstyle, but hopefully working version at http://puredata.info/downloads/plugins-plugin/releases/0.1.20120518 (of course if you can live with those extra directories).

András

(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:
<at> 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 06/02/2012 07:50 PM, s p wrote:

So, ... moving the discussion here from sourceforge's tracker :

<at> 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/yvanvolochine

_______________________________________________
Pd-dev mailing list
Pd-dev-3mXD6pJrRzU@public.gmane.org
http://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.