[PD] now that we don't have user-settable global search paths in Pd-E 0.43
Hello, Since a few years I've been using Pd-extended 0.43 incidentally, and since a few months I use it intensively. The discontinuation of user-settable global search paths made me hopping around between alternative solutions, finding out their pro's and cons by (sometimes painful) experience. Don't get me wrong - I think the discontinuation of user-settable global search paths was a good decision. Once you get the best way to work around, it's much easier to share complex patches including dependencies. Initially I preferred the 'namespaces approach'; organize abstractions in folders and instantiate them like you can instantiate objects as [cyclone/svf~], [zexy/limiter~] etc. Sometimes however I felt the need to reorganize folders with abstractions or homebrew externals. Such reorganization forces the namespaces in patches to be refactored. Not good! Then I tried [import] and [declare] instead. I settled on [declare] because it is vanilla Pd, the most flexible approach for all sorts of situations. Fortunately, [declare] doesn't report an error if a path is non-existent, so you can give several options to cover various situations if so desired. I include my home brew binaries and abstractions in subdirs of a project dir, and point to them from the main project patch with [declare -path bin], [declare -path abstractions] and so on. But ow!... with all the namespaces removed I suddenly recalled what makes namespaces so useful. Some classes exist in more than one library. A notable example is [pow~]. There's one in vanilla / Pd core and one in cyclone. Both used to have their exponent and mantissa inlets swapped as compared to [pow]. Somewhere in the Pd 0.43 series, vanilla's [pow~] was refactored to have it's inlets matching the [pow] format. So it became incompatible with Pd 0.42, while [cyclone/pow~] was still compatible with Pd 0.42 and 0.43. Namespaces are also very useful if you have collections of abstractions which you never share but only use for development purposes. For example, I have collections of oscilloscope abstractions and small math utilities. They are stored in their appropriate subdirs on one of the default location as mentioned here: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files So I can instantiate something like [scopes/scope2~] to quickly check two signal waveforms without including the path in the patch itself, and the object must be removed before the patch is shared. After struggling with Pd search paths for many years, I'm finally starting to get a grip on it. Thanks to / forced by discontinuation of user-settable global paths. No matter how, I guess this will remain tough matter for Pd beginners. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] now that we don't have user-settable global search paths in Pd-E 0.43
- Original Message - From: katja katjavet...@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Sunday, February 3, 2013 4:32 PM Subject: [PD] now that we don't have user-settable global search paths in Pd-E 0.43 [...] After struggling with Pd search paths for many years, I'm finally starting to get a grip on it. Thanks to / forced by discontinuation of user-settable global paths. No matter how, I guess this will remain tough matter for Pd beginners. It shouldn't be that way. There is currently missing functionality in Pd that makes it difficult for beginners. For example, in the 2.control/12.PART2.subpatch.pd the user is taught how to use Pd objects they've learned to create abstractions... There is a separate file in this directory named sendnumber.pd which is loaded _every_ time you type sendnumber in a box. Click on a sendnumber box above to see it. You can make changes in the subpatch and save them. The changes will be saved back to sendnumber.pd and not as part of this (containing) patch. ...(My emphasis) The problem in 0.42 is that sendnumber.pd won't load if there is an external foo/sendnumber, which may be loaded by default. The problem in 0.43 is when the user learns about externals and wants to [import foo], foo/sendnumber will override sendnumber.pd. The problem with 0.now_with_std_libs is the same as 0.42. But from the beginner's perspective, they put sendnumber.pd in the same directory as their patch, and it loads. End of story. This should be respected at the top of the hierarchy for how things get loaded-- otherwise we're teaching beginners the wrong lesson (and forcing them to correct their knowledge implicitly when what they've learned turns out not to work in obscure cases which break their patches, as with [pow~]). We're also cementing a learning curve into the software that starts with the idea of expressivity(through the use of abstractions) and ends with abstractions being 2nd class citizens and coding externalsrevealed to be the real way to get serious work done in Pd. I imagine that's one of the reasons you have a lot of homemade binaries in your bag of tricks-- if you could get the same functionality (and comparable efficiency) out of abstractions, they'd solve most of your compatibility problems. Anyway, respecting the patch's containing directory (and recursively, its subdirs) as the primary place to load stuff will require Pd to do patch-local loading, which it doesn't currently do. Only then will the beginner's lesson actually be true, and the problem with [declare] inside abstractions will go away (because the abstraction's directory will be its primary place to load stuff, too). And of course people who want to load from other locations like sys paths, etc., would still be able to do it, the same way they do it now. Well, with the small caveat that starting a new patch in a random directory (like My Downloads) may not be a good idea, but it's not in the first place... :) -Jonathan Katja ___ 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] now that we don't have user-settable global search paths in Pd-E 0.43
On 02/03/2013 06:10 PM, Jonathan Wilkes wrote: - Original Message - From: katja katjavet...@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Sunday, February 3, 2013 4:32 PM Subject: [PD] now that we don't have user-settable global search paths in Pd-E 0.43 [...] After struggling with Pd search paths for many years, I'm finally starting to get a grip on it. Thanks to / forced by discontinuation of user-settable global paths. No matter how, I guess this will remain tough matter for Pd beginners. It shouldn't be that way. There is currently missing functionality in Pd that makes it difficult for beginners. For example, in the 2.control/12.PART2.subpatch.pd the user is taught how to use Pd objects they've learned to create abstractions... There is a separate file in this directory named sendnumber.pd which is loaded _every_ time you type sendnumber in a box. Click on a sendnumber box above to see it. You can make changes in the subpatch and save them. The changes will be saved back to sendnumber.pd and not as part of this (containing) patch. ...(My emphasis) The problem in 0.42 is that sendnumber.pd won't load if there is an external foo/sendnumber, which may be loaded by default. The problem in 0.43 is when the user learns about externals and wants to [import foo], foo/sendnumber will override sendnumber.pd. The problem with 0.now_with_std_libs is the same as 0.42. But from the beginner's perspective, they put sendnumber.pd in the same directory as their patch, and it loads. End of story. This should be respected at the top of the hierarchy for how things get loaded-- otherwise we're teaching beginners the wrong lesson (and forcing them to correct their knowledge implicitly when what they've learned turns out not to work in obscure cases which break their patches, as with [pow~]). We're also cementing a learning curve into the software that starts with the idea of expressivity(through the use of abstractions) and ends with abstractions being 2nd class citizens and coding externalsrevealed to be the real way to get serious work done in Pd. I imagine that's one of the reasons you have a lot of homemade binaries in your bag of tricks-- if you could get the same functionality (and comparable efficiency) out of abstractions, they'd solve most of your compatibility problems. Anyway, respecting the patch's containing directory (and recursively, its subdirs) as the primary place to load stuff will require Pd to do patch-local loading, which it doesn't currently do. Only then will the beginner's lesson actually be true, and the problem with [declare] inside abstractions will go away (because the abstraction's directory will be its primary place to load stuff, too). And of course people who want to load from other locations like sys paths, etc., would still be able to do it, the same way they do it now. Well, with the small caveat that starting a new patch in a random directory (like My Downloads) may not be a good idea, but it's not in the first place... :) Hey Katja, Thanks for the feedback, I'm glad that, even though it was a struggle, it was worthwhile. While full canvas-local namespaces are a feature Pd should have, we can improve this situation quite a bit and solve other problems by switching the search order when loading objects. If it searches for all types in the current path first, then what Jonathan describes would no longer be a problem. Here's the proposal: http://puredata.info/dev/PdSearchPath .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] now that we don't have user-settable global search paths in Pd-E 0.43
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-list@iem.at Cc: Sent: Sunday, February 3, 2013 7:38 PM Subject: Re: [PD] now that we don't have user-settable global search paths in Pd-E 0.43 [...] While full canvas-local namespaces are a feature Pd should have, we can improve this situation quite a bit and solve other problems by switching the search order when loading objects. If it searches for all types in the current path first, then what Jonathan describes would no longer be a problem. Here's the proposal: http://puredata.info/dev/PdSearchPath Thanks for the link. -Jonathan .hc ___ 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
