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:
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.
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).
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 simpler.
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.
roman
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@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