Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-03 22:30, s p wrote: 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 gui information (e.g. spatial layout) is not always optional, sometimes it is mandatory (as in: the patch's behaviour depends on the layout) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/MWwwACgkQkX2Xpv6ydvTy1gCg2juSEq0oF38t3TDzxR09j9OR NN8An1psFQlz0VzhBcUTjdGPsc2sXD1x =ek/u -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
On Mon, Jun 4, 2012 at 2:52 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-03 22:30, s p wrote: 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 gui information (e.g. spatial layout) is not always optional, sometimes it is mandatory (as in: the patch's behaviour depends on the layout) The spatial layout dictates what connections are made, but in the .pd, doesn't this remark http://puredata.info/docs/developer/PdFileFormat#r32 (from puredata.info's docs on connect) still hold true?: Objects are virtually numbered in order of appearance in the file, starting from zero. Inlets and outlets of the objects are numbered likewise. What I'm trying to say is, the patch is reconstructed based on the order of elements within the .pd file (the proposal suggests using id's in .json). I'm I correct in assuming that spatial location is used by pd to write the patch, but its only use when reading the patch is to decide where it should be drawn? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
From: Rich E reakina...@gmail.com To: IOhannes m zmoelnig zmoel...@iem.at Cc: pd-dev@iem.at Sent: Monday, June 4, 2012 12:59 PM Subject: Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format On Mon, Jun 4, 2012 at 2:52 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-03 22:30, s p wrote: 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 gui information (e.g. spatial layout) is not always optional, sometimes it is mandatory (as in: the patch's behaviour depends on the layout) The spatial layout dictates what connections are made, but in the .pd, doesn't this remark (from puredata.info's docs on connect) still hold true?: Objects are virtually numbered in order of appearance in the file, starting from zero. Inlets and outlets of the objects are numbered likewise. What I'm trying to say is, the patch is reconstructed based on the order of elements within the .pd file (the proposal suggests using id's in .json). I'm I correct in assuming that spatial location is used by pd to write the patch, but its only use when reading the patch is to decide where it should be drawn? See [inlet] and [outlet]. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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: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 :)
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
Question: do you care about backwards compatibility, or is it a non-issue?
-Jonathan
From: s p seb...@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:
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 :)
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
On Sun, Jun 3, 2012 at 9:33 AM, s p seb...@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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
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/yvanvolochine ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
(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...@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
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
