>________________________________ >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
