Hey,
I agree in that I don't think netpd should be included in Pd-
extended. It's an application in its own right, so it makes sense to
keep it separate. What would make sense is to make libraries out of
netpd functionality and include that in Pd-extended.
For example, it would be awesome to have a generic chat client, or
even better, an IRC client, included in Pd-extended. Then netpd
could use that same one, and it could also be used to open chat rooms
from the Help menu.
.hc
On Jan 16, 2008, at 8:37 AM, Roman Haefeli wrote:
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 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 createwhile 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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra