[PD-dev] extending the .pd format

guenter geiger geiger at xdv.org
Thu Apr 1 19:07:34 CEST 2004


On Thu, 1 Apr 2004, Mathieu Bouchard wrote:
> > .. so this means no changes, right ? Surely a possible extension.
>
> It means some changes, because currently, Pd can load a patch in which "#X
> connect" has 5 or more arguments, BUT it does NOT save back the extra
> arguments.

Yes, thats true. I meant in terms of compatibility. But of course, the
problem is that editting a patch with more connect arguments in the
standard pd version would remove all of the additional information.

> > I think you would only have to change the parser, and the converter from
> > pd internal types to text representation. This should not introduce
> > changes in too many places.
>
> Cool, I'll try this eventually, though I'm not completely sure how I'll
> implement nested lists -- or how I'll avoid implementing them...

I skipped the nested lists part. Do not have any idea myself, probably its
better to avoid them for now until we have a better picture.

> > Considering that the  language itself should be kept as simple as possible
> > (everyone is happy that we do not have integer and float types anymore), I
> > think, at least for the user, there should not be a distinction between
> > symbols and strings. Where would we want to have strings ?
>
> Günter, a symboltable is not meant to be used as a textprocessing
> playground.

I understand your reasoning, but pd is not a text processing language
either. Anyhow, probably there is a solution to the problem by introducing
a garbage collection for the symbol table, or destroying unused symbols
explicitly.

> The way it's used in Pd right now, it's a big gaping glorified
> developer-approved memory leak. I guess it matters less nowadays, because
> with average textprocessing needs, even a gallery installation can stay up
> for weeks and months on a commonplace 512M RAM memory card, and I'm not
> even talking of swap partitions and swap files. Then the next barrier is
> the 2560M limit of virtual memory per process... under 32-bit Linux
> anyway... and I guess buying a 64-bit K8 -- with 16 billion gigs of
> virtual address space per process -- is easier than fixing a big gaping
> glorified developer-approved memory leak... :-}
>
> I mean I can hear John McCarthy scream in disgust and abomination... (he
> invented the symbol type back in 1958...)
>
> If there is too much resistance, I guess I'll continue developing them
> string features in terms of grids, but currently it's not possible to put
> a grid inside a list, so you can't do a list of strings of variable
> lengths, so it sort of sucks too. I guess they could be \0-padded ... I
> wonder how Jitter's string handling handles this case... if it does at
> all...

I don't really know if I am resisting, it all depends on the
implementation of strings, and how they should be handled from
the users point of view. If you look at the users list, the standard
pd user doesn't want to make a distinction between symbol "hello" and
string "hello". I think this should be hidden.

Guenter





More information about the Pd-dev mailing list