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
[PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
the patch's behaviour depends on the layout
Arr ... that's right !!!
Still, it doesn't mean that the layout is mandatory. It just means that
those infos should be extracted and saved somehow.
This should be pretty simple ... for example, if I think of inlets in a
abstraction, I guess pd infers that inlets are numbered from left to right.
So what's the problem !? Inlets can be saved with their id :
{type: inlet, id: 0}
What else do you have in mind ?
___
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
