[PD] netpd on pd-extended

Roman Haefeli reduzierer at yahoo.de
Wed Jan 16 14:37:04 CET 2008

yo hi

i try to explain how i see things, comments are still welcome, of
course. i am busy with my diploma project these days, so i might not be
accurate in every detail and i probably won't find time to work on netpd
for the next few months.

i don't think that netpd should be delivered with pd-extended for
various reasons:

- netpd writes files. this wouldn't work inside the application itself,
because at least on unix based system (and probably also in windows
since vista) a user doesn't have write access to where applications are
installed. this means, that netpd wouldn't work out of the box, but the
user would be forced to edit some configuration files, so that netpd
knows where to find patches/ and abs/ directories (which would need to
be created by the user) -> too much user work involved to setup netpd. 

- hans (or someone else with more expertise in project management than i
have) might want to correct me, if i am wrong, but i assume, that the
maintenance would become more difficult, since the structure of how
netpd would be implemented directly in pd-extended (all applications
inside the application, custom patches and abstractions outside) would
differ from the very simple layout that netpd has right now (everything
in a directory 'netpd' somewhere in the home of the user).

- i still consider netpd to be in some sort of a beta stage. though its
working and usuable, there are still some issue left, that need to be
solved. for a user updating netpd would be a pain, if some parts of it
are inside the pd-extended application. downloading a new archive of
netpd extracting it over the existing netpd installation is much

however, my goal (at least what i would like to achieve) is to make
netpd work with any flavour of pd, especially with pd-extended, out of
the box. this has become possible mainly because of the introduction of
the [declare] objectclass in pd. however, the bad news are, that miller
seems to be unsure about the correct way, how [declare] should work when
used inside abstractions. he announced in the pd-dev list, that he plans
to just disable [declare]'s inside abstractions in pd-0.41. at this
point, it's not quite clear, how this is going to affect netpd, but if
not only the '-path' flag are disabled, but also the '-sdtpath' flag,
then netpd-patches couldn't just simply declare their own dependencies
anymore (custom netpd-patches are technically abstractions inside
_creator.pd), but depedencies need to be declared beforehand (in the
pd-settingsfile, as with old versions of netpd). this definitely would
conflict with my plans to get rid of the authority of predefining a set
of dependencies. at least with pd-0.40 of any flavour, netpd-patch
developers have the freedom to declare any dependency they want and
their patches will work on any system out of the box, where those
dependencies are installed. with pd-0.41 we might have to turn back to a
more monarchic system again.

as long as such (severe) issues in pd aren't solved, i wouldn't want to
have netpd included in pd-extended.   


On Tue, 2008-01-15 at 17:13 +0100, Enrique Erne wrote:
> hi list
> i'm testing netpd on pd-0.40.3-extended-20080114.app on ppc osx 10.4.11, 
> although some synths are missing an object i think it's quite usable atm.
> the first problem i ran into was
> touch ~/Library/Preferences/org.puredata.pd.plist
> emptied the plist but didn't remove it. so it didn't load zexy and 
> maxlib, which is necessary for netpd to start and load the _chat.pd.
> removing the ~/Library/Preferences/org.puredata.pd.plist manually did 
> solve the issue. i guess when there is no org.puredata.pd.plist it takes 
> the one inside the app. couldn't it be default anyway that it takes 
> plist inside the app? and when i think further couldn't it be the same 
> file/syntax on all OS?
> then.. most netpd-patches worked in my testing session. a few synths 
> couldn't load some externals like iem_t3_lib or <~ from zexy.
> unfortunately quite a few patches have this error
>   <~
> ... couldn't create
> bon-drummer.pd
> bon-minidrm.pd
> bon-blip.pd
> bon-plucker.pd
> (the never bon-* synths all use vline and work nicely)
> t3_bpe
> ... couldn't create
>   t3_line~ 0
> ... couldn't create
>   t3_del 5
> ... couldn't create
>   t3_bpe
> ... couldn't create
>   t3_delay 5
> ... couldn't create
>   t3_sig~
> ... couldn't create
> fat-ass.pd - although i have never ever heard the sound of this synth, 
> afaik it was a license issue linux-olny.
>   blosc~ syncsaw
> ... couldn't create
>   blosc~ comparator
> ... couldn't create
>   blosc~ syncsaw
> ... couldn't create
>   blosc~ comparator
> ... couldn't create
> while testing on pd-extended i wanted to ask if there are any objection 
>   to put netpd (one day, maybe this year) into pd-extended. roman what 
> do you think?
> and if yes... how about people could add their netpd-patches to 
> pd-extended/netpd/patches?
> eni
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list