[PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format

Jonathan Wilkes jancsika at yahoo.com
Mon Jun 4 20:15:06 CEST 2012


>________________________________
>From: Rich E <reakinator at gmail.com>
>To: IOhannes m zmoelnig <zmoelnig at iem.at> 
>Cc: pd-dev at 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 <zmoelnig at 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 at iem.at
>http://lists.puredata.info/listinfo/pd-dev
>
>
>



More information about the Pd-dev mailing list