Wishlist (was Re: [PD] 3 questions regarding PD)

mark mark at junklight.com
Thu Apr 11 16:47:29 CEST 2002

One way perhaps of standardising the external situation 
would be an install menu item in pd. This would allow a 
the selection of a definition file:

external=ext example
author=Bob the Builder

or something similar. Pd would then copy the correct files to the correct 
places (and do things like saying - "you already have a more recent 
version installed - continue - yes/no"). 


-----Original Message-----
From: drjschn at gmx.de [mailto:drjschn at gmx.de]
Sent: 11 April 2002 14:37
To: pd-list at iem.kug.ac.at
Subject: Wishlist (was Re: [PD] 3 questions regarding PD)

On  9 Apr, Ivica Bukvic wrote:

Actually my time is short for the next few moths so i can not join
coding soon. But being inspired by Ico i had some thoughts to share.

> 1) Will there [ever] be the patch implemented that will allow "elbows"

Nice idea. I immediately had to think of *optional components* or
alternative specifications. If the nice 3d gui slider is missing we might
use the standard one. If we have a faster fft... Anyway, a decoupling
granularity less than a subpatch might cause confusion. Such a feature
could be implemented using pd itself but a standard mechanism would help
a lot. I would call it a configuration manager. Proper design might even
allow to substitute hardware by a software emulation. (1)

Working with pd i could easily increase my effectivity if i had a
*macro toolbox* (some sticky "insert from file" dialog). I'd love to
have a placement grid snap or some *alignment*. (Yes this is my failure
but i seem to be addicted to optical purity) *Zoom buttons* also would
be great.

> 3) What are the chances of incorporating all externals and stuff (i.e.
> Framestein, Gem etc.) together with Pd into one simple installer, rather
> than having to look for all of them all over the net?

Since a lot of modules exist and many of them implement functionality of
common interest i also had an itch calling for compilations. The idea is
good but how to support "open" in "open source"?

The modules interdepend somehow. Compilations should not become
necessary as a whole to use a particular module. If one provides a
dependency checking automagic download and install tool it should have a
finer granularity than compilations. (BTW "compilations" - lets
brainstorm: gui, audio, video, math, scripting, control and connection,

We need:

- a download list. pure-data.org could host (it does already somehow)
- check dependencies. tool and component interface
- compile and install (tool and interface)
- documentation is most important since standards will only be used if
  documented properly.

Maybe extend the current directory structure.

Have i overlooked a wishlist on any pd related website?

- Robert Figura


(1): For more notions see "Generative Programming", by Czarnecki,
     Eisenhecker, 2000.

/* mandlsig.c v0.23                       (c) by Robert Figura */
I=1702;float O,o,i;main(l){for(;I--;putchar("oO .,\nm>cot.bitamea\
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l=

More information about the Pd-list mailing list