Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On 6/18/07, Roman Haefeli [EMAIL PROTECTED] wrote: luckily just yesterday, i had a (very simple) idea, for which i waited for years: instead of opening the netpd-patches with the (for me) inconvenient 'open'-message, i want to load them as abstractions. this has the BIG advantage, that i can specify the location of a patch (now abstraction) relative to the parent patch (creator in this case). by doing that i can get rid of the very unwanted 'netpd-path' setting. AND this has a very nice side effect: when all patches are actually the same patch, i can add a search patch with only one [declare], that is valid for all loaded netpd-patches (now abstractions). in short: in future versions of netpd there will be no need for 'netpd-path' and for a -path flag anymore. there is one critical point left: having to have loaded the right externals. with [declare], each netpd-patch can define for itself, what it wants to have loaded. that means, the only thing, a user will have to care, is to have installed the needed externals (which is the case anyway in extended) This is great! I also like an additional feature of this method that you did not mention. When closing an instrument window, right now it will actually cause the instrument to disappear. I think that I actually inadvertantly crashed netpd a few times by doing this (since I am used to closing abstraction windows and subpatches to free visual space, but keeping them running still). So now, with this new idea, you would be able to close these windows in the normal way without it affecting netpd sessions. Sorry if I ruined your sessions ever by doing this!!! i actually don't have time to implement all these changes and afaik the actual stable release of pd-extended is based on 0.39, which lacks [declare]. but when pd-extended switches to 0.40 and i'll have made the necessary changes, things will be hopefully much easier than today for eveveryone, the pd-extended users and pd-vanilla/external users. You could actually start working on Pd-0.40-extended, as it is already auto building every night! ~Kyle -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Tue, 2007-06-19 at 11:47 -0500, Kyle Klipowicz wrote: On 6/18/07, Roman Haefeli [EMAIL PROTECTED] wrote: luckily just yesterday, i had a (very simple) idea, for which i waited for years: instead of opening the netpd-patches with the (for me) inconvenient 'open'-message, i want to load them as abstractions. this has the BIG advantage, that i can specify the location of a patch (now abstraction) relative to the parent patch (creator in this case). by doing that i can get rid of the very unwanted 'netpd-path' setting. AND this has a very nice side effect: when all patches are actually the same patch, i can add a search patch with only one [declare], that is valid for all loaded netpd-patches (now abstractions). in short: in future versions of netpd there will be no need for 'netpd-path' and for a -path flag anymore. there is one critical point left: having to have loaded the right externals. with [declare], each netpd-patch can define for itself, what it wants to have loaded. that means, the only thing, a user will have to care, is to have installed the needed externals (which is the case anyway in extended) This is great! I also like an additional feature of this method that you did not mention. When closing an instrument window, right now it will actually cause the instrument to disappear. I think that I actually inadvertantly crashed netpd a few times by doing this (since I am used to closing abstraction windows and subpatches to free visual space, but keeping them running still). Usually you should only see the gui of a patch, not the main patch itself (except when you are interested in seeing the internals of a certain patch). but it's true, that the patch gets closed then unintentionally, though this shouldn't crash pd. and if your pd crashes then, it doesn't harm the session at all. you can just restart pd/netpd and join the session, without the others noticing that you crashed. So now, with this new idea, you would be able to close these windows in the normal way without it affecting netpd sessions. yeah, true. i didn't think about this side effect yet. Sorry if I ruined your sessions ever by doing this!!! you certainly never did. and still if you did, nevermind, we are doing it for fun.. ;-) i actually don't have time to implement all these changes and afaik the actual stable release of pd-extended is based on 0.39, which lacks [declare]. but when pd-extended switches to 0.40 and i'll have made the necessary changes, things will be hopefully much easier than today for eveveryone, the pd-extended users and pd-vanilla/external users. You could actually start working on Pd-0.40-extended, as it is already auto building every night! i think, it doesn't need any extra work to make it work in pd-0.40-extended. so it is just a matter of finding free time (aah, i a few weeks we'll have summer vacation...yeah!) roman ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Jun 14, 2007, at 1:07 PM, Roman Haefeli wrote: On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote: It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. reading that post a second time, i feel somehow insulted by your assumption, that i consciously do not fix things, that simply could be fixed spending a day for them. so, please tell me, what do you think needs to be fixed? Certainly no insult of any kind was intended. I was just quite frustrated by the experience. We were having a network jam at the end of the NIME conference, a few of us wanted to use netpd. But only Alexandre was able to get it running. Please don't take my comments to be saying something bad about your skills or the work you put it. It can be a hard problem to solve, getting everything running smoothly, but it is certainly possible. You have been very good at providing help for people to get it up and running. I'd just like to see netpd get to the point where you can spend less time helping people get it running and more time improving things. In the general terms, I think it should be quite possible to make netpd just work on any Pd-extended install with the user just opening a patch in Pd. If you want to base netpd on pd-vanilla, then you'll need to provide any externals that are needed for the various platforms. As for my problem at the NIME jam, I wasn't really able to pinpoint the problem. But I'll work thru it with you sometime. Basically, take a machine that doesn't have netpd running, take a fresh, untouched Pd install, and try running netpd. For each step the stops it from running, try to fix it without changing the environment or the Pd startup settings. .hc roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Mon, 2007-06-18 at 19:05 -0400, Hans-Christoph Steiner wrote: On Jun 14, 2007, at 1:07 PM, Roman Haefeli wrote: On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote: It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. reading that post a second time, i feel somehow insulted by your assumption, that i consciously do not fix things, that simply could be fixed spending a day for them. so, please tell me, what do you think needs to be fixed? Certainly no insult of any kind was intended. I was just quite frustrated by the experience. We were having a network jam at the end of the NIME conference, a few of us wanted to use netpd. But only Alexandre was able to get it running. hm, i am sorry about that. Please don't take my comments to be saying something bad about your skills or the work you put it. It can be a hard problem to solve, getting everything running smoothly, but it is certainly possible. You have been very good at providing help for people to get it up and running. I'd just like to see netpd get to the point where you can spend less time helping people get it running and more time improving things. as i said, i know the problems (if they could be considered as problems), but didn't find a way around them. In the general terms, I think it should be quite possible to make netpd just work on any Pd-extended install with the user just opening a patch in Pd. If you want to base netpd on pd-vanilla, then you'll need to provide any externals that are needed for the various platforms. netpd actually should 'just' work with any pd-installation, though three points are critical: - having the right externals loaded (that is: zexy, maxlib, iemmatrix, iemlib1, iemlib2, iem_t3_lib) - having the correct netpd-path in the netpd-settings dialog (this one annoys me most, because it is due to the 'open-message-path-is-relative-to-pd's-startlocation'-problem [to mention this problem again]) -having netpd/abs in the pathes if these settings are correct and netpd is still not working, then something is definitely wrong. luckily just yesterday, i had a (very simple) idea, for which i waited for years: instead of opening the netpd-patches with the (for me) inconvenient 'open'-message, i want to load them as abstractions. this has the BIG advantage, that i can specify the location of a patch (now abstraction) relative to the parent patch (creator in this case). by doing that i can get rid of the very unwanted 'netpd-path' setting. AND this has a very nice side effect: when all patches are actually the same patch, i can add a search patch with only one [declare], that is valid for all loaded netpd-patches (now abstractions). in short: in future versions of netpd there will be no need for 'netpd-path' and for a -path flag anymore. there is one critical point left: having to have loaded the right externals. with [declare], each netpd-patch can define for itself, what it wants to have loaded. that means, the only thing, a user will have to care, is to have installed the needed externals (which is the case anyway in extended) i actually don't have time to implement all these changes and afaik the actual stable release of pd-extended is based on 0.39, which lacks [declare]. but when pd-extended switches to 0.40 and i'll have made the necessary changes, things will be hopefully much easier than today for eveveryone, the pd-extended users and pd-vanilla/external users. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Jun 14, 2007, at 3:08 PM, Patco wrote: does getdir work without [import]? Why wouldn't it work without [import]? I've got it working so fine without the help of any ohter stuff than vanilla. Pk ah i am not sure about pd-extended's flatspace. when to use [ggee/getdir], [import ggee], -lib ggee, or just [getdir] ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo! ah i am not sure about pd-extended's flatspace. when to use [ggee/getdir], [import ggee], -lib ggee, or just [getdir] If getdir is in ggee, then you can use [ggee/getdir] or [import ggee] and [getdir] or -lib ggee and [getdir] LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Thu, Jun 14, 2007 at 11:17:57AM +0200, Roman Haefeli wrote: the question is: how should they be included? should they be included as they are now, with the gui and their dependency on the netpd-framework? or would it make more sense to strip everything off to get a working subset of abstractions, that can be used in a more flexible way? as far as i understand the concept of pd-extended as a collection of abstractions and externals (read: collection of tools/utility rather than a collection of examples), i'd vote for the latter, though that would involve a lot more work. i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended. One thing that would be cool for us to come up with is some way to abstract the core, and gui of abstractions separately in such a way that they could be used in multiple different state saving/communication paradigms. For example, if I could make one abstraction for the s-abstractions collection and then have the user be able to choose whether it: 1. saves using sssad, has a GOP gui 2. saves using memento, has a GOP gui 3. integrates with netpd, has netpd style gui This could just be a pipe dream, but then again I could never have imagined someone creating something as amazing as netpd or sssad in Pure Data alone. Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote: One thing that would be cool for us to come up with is some way to abstract the core, and gui of abstractions separately in such a way that they could be used in multiple different state saving/communication paradigms. For example, if I could make one abstraction for the s-abstractions collection and then have the user be able to choose whether it: 1. saves using sssad, has a GOP gui 2. saves using memento, has a GOP gui 3. integrates with netpd, has netpd style gui This could just be a pipe dream, but then again I could never have imagined someone creating something as amazing as netpd or sssad in Pure Data alone. This is not a pipe dream, if a pipe dream is, what I guess a pipe dream is. All that would be necessary are a clean and documented interfaces for the DSP abstractions. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hello, Frank Barknecht a écrit : All that would be necessary are a clean and documented interfaces for the DSP abstractions. Yes exactly. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions. It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction, and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction. salute ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Fri, 2007-06-08 at 16:07 -0500, Kyle Klipowicz wrote: You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736atid=478070 direct link]. I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! because nobody included them yet. ;-) Seriously, they are the most functional and useable get-started-out-of-box things to represent Pd around, and they are not in Pd-extended! the question is: how should they be included? should they be included as they are now, with the gui and their dependency on the netpd-framework? or would it make more sense to strip everything off to get a working subset of abstractions, that can be used in a more flexible way? as far as i understand the concept of pd-extended as a collection of abstractions and externals (read: collection of tools/utility rather than a collection of examples), i'd vote for the latter, though that would involve a lot more work. i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo Roman! i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended. I can include them if you want. If you have lots of abstraction and also want to maintain them yourself maybe its also option that you get write access to cvs ? LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Sat, 2007-06-09 at 08:57 -0500, Kyle Klipowicz wrote: Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own. yeah, that is what i think as well. These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!). a netpd-patch is a patch with a gui-subpatch, that uses some netpd-abstractions and possibly some others, but usually they don't use GOP. either turning them into GOP-modules or just into abstractions, both would require at least a minimum of work (and writing some help-patches). In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way? this topic was never seriously discussed and it is not clear, if and how the netpd-patches could be generally licensed. but since it is known, that a patch opened in netpd is distributed within the whole community, one can assume, that these patches are meant to be shared. If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone? i don't think that it is realistic to expect people to maintain there patches in cvs. and i think it is more a question of porting the patches to generally useful modules than of maintaining these modules, since i don't believe that people who made some patches for netpd will maintain the modules derived from their patches over years. roman ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Sat, 2007-06-09 at 09:11 -0500, Kyle Klipowicz wrote: On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site? yes, i think so (unfortunately). it would be surely very useful to provide an archive of all patches. it's just that i don't know how to do it automatically, so that it doesn't need to be updated manually everyweek. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Roman Haefeli wrote: On Sat, 2007-06-09 at 09:11 -0500, Kyle Klipowicz wrote: On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site? yes, i think so (unfortunately). it would be surely very useful to provide an archive of all patches. it's just that i don't know how to do it automatically, so that it doesn't need to be updated manually everyweek. roman ola roman why not just make again a dummy user, and his netpd-folder would be in public_html? greets from stressed moritz ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Sun, 2007-06-10 at 11:45 +0200, Enrique Erne wrote: However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice. there has been a state saving system for a long time and on it a preset administrator (which i just fixed yesterday) which breaks the netpd presetfile syntax. we'll have to talk about this again. i don't think that a patch that has its own implementation of saving and loading presets and whose presets are not compatible with presets made the standard way should be considered as the standard tool for saving and loading presets in netpd. roman ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Mon, 2007-06-11 at 00:40 -0500, Kyle Klipowicz wrote: Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction? yeah, absolutely. as often, it is a question of someone doing the work. roman ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Tue, 2007-06-12 at 15:17 +0200, Georg Holzmann wrote: Hallo! maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version. you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ... But I don't know much about netpd so I migth be wrong ... two prerequisites must be fullfilled in order to work netpd-patches in standalone mode in pd-extended: a) netpd-abs need to be included as well b) an additional patch, that imitates the netpd-server would be needed. basically that patch would just be: [r netpd-broadcast] | | [r netpd-send] | | | [list split 1] | / | / |/ [s netpd-receive] (yeah, in ascii art you can have segmented patch cords ;-) ) roman ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Tue, 2007-06-12 at 21:42 -0400, Hans-Christoph Steiner wrote: netpd has been changing a lot over the last years, and things that change a lot don't work well in Pd-extended. You get version troubles, etc. maybe i am blind to see the obvious solution, but the main problem i see in including netpd into pd-extended is a complete different one: at least the patches and the abstraction folders need to be outside the package, since a user needs to have a writing access to these while using netpd. if netpd would be included into pd-extended, either one has to create the necessary folders him/herself, or pd-extended would create them in whereever (assumingly /home/user/netpd, resp. /User/npetd), which is ugly and very unconvenient, if someone doesn't have any plans to use netpd at all. I'd really like to see a lot of the netpd code made into reusable objects and gathered into libs. yep. i also think this is a good idea. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote: On Jun 9, 2007, at 5:45 AM, Enrique Erne wrote: I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) This right here outlines the main purpose of Pd-extended: to provide a tested and reliable package that works the same on all OSes. Basically, I think you should pick one platform for netpd, and make sure everything works smoothly on that one. Then worry about the rest. hm, that is what netpd basically does: pd-vanilla, zexy, maxlib, that's it. these work quite the same on all os/platforms and i think also in pd-extended for every os/platform. Alex Quessy and I tried to run the latest version on netpd working for a network jam last Sunday, we both failed. He got further than me, he got some sounds out, but neither got it all working. Both of us know quite a bit about Pd, so I am amazed that newbies get it going (do they?). this might be rather due to bad documentation than difficulty of installing netpd. newbies often just download pd-netpd for win or osx and that works just out of the box. It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. hmcan you elaborate a bit more what you mean by 'fixing' stuff? i know there are some drawbacks while installing netpd and i would sure fix them, if i knew how to do it: a) the user needs to add '-path /path/to/netpd/abs' to his/her startup script. i'd love to get rid of this, but i don't see a way, since [declare -path netpd/abs] does only work withing the patch, but not for the whole pd-instance. b) the user needs to set the path of the netpd-folder in 'netpd-settings' (see appropriate button in chat-window). since the 'open'-message to 'pd' is relative to pd's start location and NOT relative to the patch's location, the user needs to set it manually (if not using the pd-netpd-package), because there is no way to get the start-location in pd. since i am sure, that the actual behaviour of the 'open'-message doesn't make any sense at all, i hope it will be changed to 'relative to the patch' in the future. if not, i might consider using 'getdir' to overcome this problem. i think these undesired, but atm necessary user interactions are the main cause for any troubles while installing netpd and i assume, these were the reason, why you and a.quessy had troubles installing netpd. have you better ideas to overcome these problems? roman .hc Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... are you talking about basic netpd or netpd all the instruments... basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote: Alex Quessy and I tried to run the latest version on netpd working for a network jam last Sunday, we both failed. He got further than me, he got some sounds out, but neither got it all working. Both of us know quite a bit about Pd, so I am amazed that newbies get it going (do they?). not, that kyle is a pd-newbie, but sure a netpd-newbie: http://lists.puredata.info/pipermail/pd-list/2007-06/051021.html roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Wed, 2007-06-13 at 11:21 -0400, Hans-Christoph Steiner wrote: I think it should not be too hard to make netpd double-clickable with no extra setup at all (setting .pdrc, etc.) without embedding it into it's own Pd install. but this works smoothly and i think it is the only option, so that non-pd-users are willing install netpd. The key is just trying it on other people's machines, and finding the common access methods that work across OSes. again, can you elaborate that a bit more? how can the startup-script be edited by a double click installer in a manner, that it works with every pd-installation? the main problem i see here, that (in contrary to other programing languages, if pd is considered as a programing language) pd lacks any feedback about loaded pathes and externals. if there would be a way to check within pd, if a certain external was loaded, a netpd-user would at least know, why it does not work as expected. also for the other issue with the netpd-path, using 'getdir' would be just a workaround, but not the solution for the problem (since using additional externals in an environment like pd increases the chance of having troubles anyway). roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
The helpfile aspect would be very much appreciated! I think that modular is better so that people can reuse netpd elements in their own patches. Of course, being able to use the sequencers and mixer + fx would be the primary Reason (forgive the semi-pun) for newbies to adopt the objects. ~Kyle On 6/14/07, Roman Haefeli [EMAIL PROTECTED] wrote: i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote: It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. reading that post a second time, i feel somehow insulted by your assumption, that i consciously do not fix things, that simply could be fixed spending a day for them. so, please tell me, what do you think needs to be fixed? roman ___ 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
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Good idea. There could be a script called by cron to automatically tarball this dir every week. ~Kyle On 6/14/07, moritz [EMAIL PROTECTED] wrote: Roman Haefeli wrote: On Sat, 2007-06-09 at 09:11 -0500, Kyle Klipowicz wrote: On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site? yes, i think so (unfortunately). it would be surely very useful to provide an archive of all patches. it's just that i don't know how to do it automatically, so that it doesn't need to be updated manually everyweek. roman ola roman why not just make again a dummy user, and his netpd-folder would be in public_html? greets from stressed moritz -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Great! This seems easy enough. I think that this is the simplest solution for now anyway. Eventually being able to separately use modules and even create alternate GUIs for them would be nice too. Of course, I think that the GUIs in netpd are one of the most attractive aspects for new users (and people like me who appreciate thoughtful design). So it sounds like Georg is offering to add this stuff to CVS. What are the major decisions then that need to be made to get this thing rolling? I've got these: 1) Decide whether or not to take a static sampling of the netpd community at a certain point, or keep this updated fluidly like netpd itself. 2) Decide if the files will emulate netpd by mimicking the _controller.pd patch and server-side communications, or if they will be rewritten in another way. 3) Find the best way to keep the files checked in to cvs. 4) Actually check it in. 5) Test it out. 6) Fix errors. I think that using the namespace features of Pd-extended will be very nice if one would wish to run both the netpd online community, as well as the independent Pd-extended version. Any thoughts or additions to this quick list of steps to be done? ~Kyle On 6/14/07, Roman Haefeli [EMAIL PROTECTED] wrote: On Tue, 2007-06-12 at 15:17 +0200, Georg Holzmann wrote: Hallo! maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version. you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ... But I don't know much about netpd so I migth be wrong ... two prerequisites must be fullfilled in order to work netpd-patches in standalone mode in pd-extended: a) netpd-abs need to be included as well b) an additional patch, that imitates the netpd-server would be needed. basically that patch would just be: [r netpd-broadcast] | | [r netpd-send] | | | [list split 1] | / | / |/ [s netpd-receive] (yeah, in ascii art you can have segmented patch cords ;-) ) roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hello Eni, Enrique Erne a écrit : does getdir work without [import]? regards eni Why wouldn't it work without [import]? I've got it working so fine without the help of any ohter stuff than vanilla. Pk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
i'm glad you like it. was it hard to install? if i'd maintain it into cvs first thing i would do is add plain/basic netpd. then i would add some patches to the 2 directories netpd/patches and netpd/abs. btw. if you disconnect the chat from the netpd server everything works locally. it opens a bridge from [s netpd-broadcast] to [r netpd-receive] i want to know romans opnion about (netpd)U(Pd-extended) On Jun 12, 2007, at 6:38 PM, Kyle Klipowicz wrote: After playing around a little bit with netpd over the past few days, I think that it would be possible to write a dummy _controller.pd that would allow a user to have the netpd experience without an internet connection. Maybe this could be included with a pd-extended netpd library (as well as the REAL controller) so that users could use the modules for their own purposes beyond the collective jam session. Also to Eni, Roman and whoever else is involved: I'm totally impressed by netpd guys! This is a very usable piece of software and the community aspect is very welcoming. Keep up the good work! ~Kyle On 6/12/07, Georg Holzmann [EMAIL PROTECTED] wrote: Hallo! maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version. you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ... But I don't know much about netpd so I migth be wrong ... LG Georg -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
hello hans On Jun 13, 2007, at 3:46 AM, Hans-Christoph Steiner wrote: on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) This right here outlines the main purpose of Pd-extended: to provide a tested and reliable package that works the same on all OSes. Basically, I think you should pick one platform for netpd, and make sure everything works smoothly on that one. Then worry about the rest. picking one platform for netpd is not possible. i doubt roman will change to osx ;-), people have been developing under all OS. for me there is no current pd-extended on osx 10.3.9 (right now i can't change to 10.4 or linux) Alex Quessy and I tried to run the latest version on netpd working for a network jam last Sunday, we both failed. He got further than me, he got some sounds out, but neither got it all working. what didn't work? that day i saw you guys in the log file.. you managed to login to netpd. unfortunately nobody was there to help you and upload the right patches. downloading all the instruments form the wiki is not ideal to start with netpd. you need at least 3 patches to get a sound: master.pd, qseq2.pd and a drummachine. things like that are not documented anywhere. Both of us know quite a bit about Pd, so I am amazed that newbies get it going (do they?). well they should easily manage to connect and then usually somebody gives a little intro to the netpd jungle. at the moment only newbies on windows have a double clickable netpd package. the package on osx is currently not working because of 10.3/10.4/ppc/intel + externals . there never was a linux package so far. It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. that's true. what do you suggest? what technology would be required? i think getdir would solve the whole path issue. does getdir work without [import]? since we netload patches with openpanel it would be better to have the netpd directory not inside the .app , but it would be indise the .app if it is in the cvs right? regards eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Jun 13, 2007, at 4:10 AM, Enrique Erne wrote: hello hans On Jun 13, 2007, at 3:46 AM, Hans-Christoph Steiner wrote: on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) This right here outlines the main purpose of Pd-extended: to provide a tested and reliable package that works the same on all OSes. Basically, I think you should pick one platform for netpd, and make sure everything works smoothly on that one. Then worry about the rest. picking one platform for netpd is not possible. i doubt roman will change to osx ;-), people have been developing under all OS. for me there is no current pd-extended on osx 10.3.9 (right now i can't change to 10.4 or linux) Sorry, I should have used a different word. By platform, I mean pd- vanilla, pd-extended, desiredata, pd-devel, jmax, whatever. I did not mean choose an OS. For things not supported on that platform would have to be taken care of by the patch authors. Alex Quessy and I tried to run the latest version on netpd working for a network jam last Sunday, we both failed. He got further than me, he got some sounds out, but neither got it all working. what didn't work? that day i saw you guys in the log file.. you managed to login to netpd. unfortunately nobody was there to help you and upload the right patches. downloading all the instruments form the wiki is not ideal to start with netpd. you need at least 3 patches to get a sound: master.pd, qseq2.pd and a drummachine. things like that are not documented anywhere. A bunch of things, missing objects, crashes, trouble uploading patches. I could only get patches to work when Alex uploaded them from his GNU/Linux machine. I gave up when I got things running, but no instruments would show up to select in the qsec2 scroll bars. I could tweak the sequences that Alex had made. Both of us know quite a bit about Pd, so I am amazed that newbies get it going (do they?). well they should easily manage to connect and then usually somebody gives a little intro to the netpd jungle. at the moment only newbies on windows have a double clickable netpd package. the package on osx is currently not working because of 10.3/10.4/ppc/intel + externals . there never was a linux package so far. It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. that's true. what do you suggest? what technology would be required? i think getdir would solve the whole path issue. does getdir work without [import]? You can load getdir like this: [ggee/getdir]. But this is what I mean by choose a platform. Pd-extended provides getdir in the same place on all platforms. If you used pd-vanilla, you would then need to bundle getdir for each platform, and so on and so forth. since we netload patches with openpanel it would be better to have the netpd directory not inside the .app , but it would be indise the .app if it is in the cvs right? I think it should not be too hard to make netpd double-clickable with no extra setup at all (setting .pdrc, etc.) without embedding it into it's own Pd install. The key is just trying it on other people's machines, and finding the common access methods that work across OSes. .hc regards eni There is no way to peace, peace is the way. -A.J. Muste ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo! maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version. you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ... But I don't know much about netpd so I migth be wrong ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
After playing around a little bit with netpd over the past few days, I think that it would be possible to write a dummy _controller.pd that would allow a user to have the netpd experience without an internet connection. Maybe this could be included with a pd-extended netpd library (as well as the REAL controller) so that users could use the modules for their own purposes beyond the collective jam session. Also to Eni, Roman and whoever else is involved: I'm totally impressed by netpd guys! This is a very usable piece of software and the community aspect is very welcoming. Keep up the good work! ~Kyle On 6/12/07, Georg Holzmann [EMAIL PROTECTED] wrote: Hallo! maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version. you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ... But I don't know much about netpd so I migth be wrong ... LG Georg -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Jun 9, 2007, at 5:45 AM, Enrique Erne wrote: I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) This right here outlines the main purpose of Pd-extended: to provide a tested and reliable package that works the same on all OSes. Basically, I think you should pick one platform for netpd, and make sure everything works smoothly on that one. Then worry about the rest. Alex Quessy and I tried to run the latest version on netpd working for a network jam last Sunday, we both failed. He got further than me, he got some sounds out, but neither got it all working. Both of us know quite a bit about Pd, so I am amazed that newbies get it going (do they?). It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things. .hc Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... are you talking about basic netpd or netpd all the instruments... basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo! I am not meaning that people will add to netpd from Pd-extended. Rather, it would be neat to 'steal' the great functional modules that are in netpd and use them as standalone modules for rapid building of non-netpd patches. Say, if a person has been using Reason for a few years, but wants to upgrade. The netpd abstractions that I've looked over on the netpd site seem to be fairly strait forward in GUI and purpose that a Reason Seasoned (couldn't resist the rhyme) user could take these modules and build their own patches with them, APART from netpd. Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction? Yes, that's also what I meant - this would be nice ... I don't know who is the maintainer of the netpd community - maybe someone could maintain these objects in CVS ? (then this could be also used as a central place for checking out the latest patches ...) If it is not changing too much I can also add them to CVS ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
hi Georg On Jun 11, 2007, at 9:25 AM, Georg Holzmann wrote: I am not meaning that people will add to netpd from Pd-extended. Rather, it would be neat to 'steal' the great functional modules that are in netpd and use them as standalone modules for rapid building of non-netpd patches. Say, if a person has been using Reason for a few years, but wants to upgrade. The netpd abstractions that I've looked over on the netpd site seem to be fairly strait forward in GUI and purpose that a Reason Seasoned (couldn't resist the rhyme) user could take these modules and build their own patches with them, APART from netpd. Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction? Yes, that's also what I meant - this would be nice ... I don't know who is the maintainer of the netpd community - maybe hehe ... well who is the maintainer of the puredata community ? the netpd-wiki is open. everyone can edit and add to the wiki and many did so. maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version. someone could maintain these objects in CVS ? (then this could be also used as a central place for checking out the latest patches ...) well not for netpd itself. - if they have to be standalone i guess they wouldn't work anymore with netpd - if you would include the original patches then i'd rather add only netpd and let the user download the newest patches over netpd. - an other disadvantage of the cvs (please correct me if i'm wrong) one has to be pd-dev to make changes in cvs, that means not everybody could add netpd-patches to the central place ... also in my eyes the netpd wiki is _not_ the central place to add patches. it is only a public place to show some patches or write documentation for it. i think the central place to add netpd-patches is netloading patches in _creator.pd . btw. mMm is working standalone but unlike a netpd-instrument it doesn't use the usual netpd-abstractions. so far... well i have to go back to work and would like to know romans opinion about this topic. cheers eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
good morning Kyle i would only add the basic netpd to Pd-extended without any instrument, so that any user can get the newest version of the instruments through creator without maintaining all the instruments in cvs. the netpd-instruments are using some basic netpd-abstractions for broadcasting, synchronizing and statesaving so they wont work without netpd anyway. little correction: the instruments are not Graph On Parent abstractions but patches with their GUI in a subpatch named: [pd synthname-gui] i'm pretty green about cvs. over the pasat 3 years there have been at least 10 different people writing instruments for netpd. how is this done in other projects... like pixeltango or rradical are they maintained in cvs by one person or has anybody access to change everything? regards eni On Jun 9, 2007, at 3:57 PM, Kyle Klipowicz wrote: Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own. These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!). In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way? If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone? ~Kyle On 6/9/07, Enrique Erne [EMAIL PROTECTED] wrote: I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... are you talking about basic netpd or netpd all the instruments... basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors. -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote: i'm pretty green about cvs. over the pasat 3 years there have been at least 10 different people writing instruments for netpd. how is this done in other projects... like pixeltango or rradical are they maintained in cvs by one person or has anybody access to change everything? It depends. Generally the CVS on Sourceforge has almost no access control: Everyone can overwrite everyone else's patches. It's based on trust that this doesn't happen unless with permission. Some sub-projects are maintained by several people, like mapping, which is Hans and Cyrille and maybe more, or purepd which contains patches by several people. Others are more a one-person issue, like RTC-lib. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On Jun 9, 2007, at 4:11 PM, Kyle Klipowicz wrote: On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, there is no tarball. and if there would be it would be not up to date within short time. of will I have to go to each description page on the netpd site? i wouldn't do that because there are not all instruments available. and maybe it's not the newest version. somebody could make an archive of his current netpd directory and send it to you. or we check the idea of adding only netpd to the cvs and so everybody can get it online. if people start writing patches using pd-extended and all it's externals we will probably have many new external related and os specific bugs and patches that wont work on everybody's system. The largest challenge with this idea is the extra machinery for synchronization between netpd elements. why do you want a extra machinery .. there is synchronization from a patch called master.pd (global metro) However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice. there has been a state saving system for a long time and on it a preset administrator (which i just fixed yesterday) ~Kyle ciao eni On 6/9/07, Kyle Klipowicz [EMAIL PROTECTED] wrote: Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own. These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!). In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way? If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone? ~Kyle On 6/9/07, Enrique Erne [EMAIL PROTECTED] wrote: I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... are you talking about basic netpd or netpd all the instruments... basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors. -- - - - -- http://perhapsidid.wordpress.com -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo! Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... Everyone could integreate them to her/his own pd-extended using a simple -path flatspace, as AFAIK everything netpd uses is already there and people not using pd-extended wouldn't have tons of import: couldn't create error messages. No, zexy and iemlib is not in flatspace ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own. These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!). In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way? If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone? ~Kyle On 6/9/07, Enrique Erne [EMAIL PROTECTED] wrote: I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... are you talking about basic netpd or netpd all the instruments... basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors. -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site? The largest challenge with this idea is the extra machinery for synchronization between netpd elements. However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice. ~Kyle On 6/9/07, Kyle Klipowicz [EMAIL PROTECTED] wrote: Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own. These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!). In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way? If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone? ~Kyle On 6/9/07, Enrique Erne [EMAIL PROTECTED] wrote: I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows. if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-) Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... are you talking about basic netpd or netpd all the instruments... basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors. -- - - - -- http://perhapsidid.wordpress.com -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736atid=478070 direct link]. I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! Seriously, they are the most functional and useable get-started-out-of-box things to represent Pd around, and they are not in Pd-extended! ~Kyle On 6/8/07, patrice colet [EMAIL PROTECTED] wrote: Le vendredi 08 juin 2007 à 21:35 +0200, Georg Holzmann a écrit : And you are invited to help - cleaning up some patches, adding comments, include out-of-the-box examples, Where would I submit corrected files? -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (netpd)U(Pd-extended), Pd-ext bug-tracker (was Re: elitism, software and academia)
Hallo! You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736atid=478070 direct link]. Yes, or if you have a useful bundle of patches that work out of the box with pd extended just send them to me or to the list and I will add them to the abstractions of pd extended ... Or you could of course also correct some of the already included abstractions (which are quite a lot) - because most of the don't work out of the box with all the externals ! I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?! Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
