Hey all,
I just had an idea suddenly inspired by Frank's RRADical announcement.
There has been a lot of talk about naming collisions and such on the list (indeed I have also been a victim myself of such issues) having to do with abstractions and objects. I started by naming my abstractions by the project they belong to ie v_[name] and pt.[name] but I realized something that could make managing this stuff a lot easier (Though it could make object names much more verbose, and could cause a hell of a time with existing patches being broken)
For example I have an Gem abstraction that does pix filtering called pt.layerfx.pd this abstraction is in one of the PDs paths. This abstraction depends on a number of other abstractions that are at a lower level. These abstractions are not meant for the person patching but only to make things easier for pt.layerfx. I have taken a few of the pix_ filters and wrapped them in abstractions to standardize their interface. They all have one inlet for the amount of the effect (from 0-1) and an inlet and outlet for the gem-chain. These lower-level abstractions are in a sub folder of the folder that contains pt.layerfx called fx. Since the sub folder "fx" is not in the PD path typing "rtx" (the name of one of these wrapper-abstractions) for example gives me no valid object. Though if I type fx/rtx I am actually calling the correct abstraction, even though that abstraction is not in the PD path.
One could then organize their abstractions by the project and add only the folder of projects to the path rather than the individual project folders. This way you use a more verbose name to get at all the same abstractions without name collisions. A folder of cvs abstractions that may not be stable for example could be called as cvs/pt.layerfx and the stable version could be called simply as pt.layerfx.
Could this method be applied to externals as well?
markex/counter or mex/counter cxc/counter cyclone/counter or cyc/counter
Of course you break all the old patches if you have to use new names, but it provides a facility where you use the object you want rather than the one with the same name as the object you want. Shorter project names, or project aliases could be used for shorter names pt.layerfx becomes pt/layerfx. Someone could always put the cyclone folder into the PD path and then "counter" would refer to cyclone, and if you want the markex version you type markex/counter.
So there are issues with this method but I think it has potential. Obviously it could use development but I think the concept has some validity. In a way this is creating a seperate namspace for each set of abstractions/externals. They could also be multiple levels deep:
cvs/markex/counter cvs/cyclone/counter markex/counter cyclone/counter
Just throught I would throw it out there as fast as it popped into my brain.
Any comments?
Ben
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
These lower-level abstractions are in a sub folder of the folder that contains pt.layerfx called fx. Since the sub folder "fx" is not in the PD path typing "rtx" (the name of one of these wrapper-abstractions) for example gives me no valid object. Though if I type fx/rtx I am actually calling the correct abstraction, even though that abstraction is not in the PD path.
Great idea, I'd love to see this implemented somehow. Maybe it even works already?
Currently I just prepend those patches, not intended for public use with an underscore, but this of course doesn't help against name clashes at all.
Ciao
Hey Frank,
Thanks for the inspiration.
Indeed it already does work for abstractions (and probably externals too though I have not tried it)
I'm attaching a really simple example that proves the concept with abstractions.
Add the "pd_path" directory to your PD path and then open the "user_patch.pd" patch to begin. Once the pd_path is in your path you can move the user_patch.pd to wherever and it will still work.
Ben
Frank Barknecht wrote:
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
These lower-level abstractions are in a sub folder of the folder that contains pt.layerfx called fx. Since the sub folder "fx" is not in the PD path typing "rtx" (the name of one of these wrapper-abstractions) for example gives me no valid object. Though if I type fx/rtx I am actually calling the correct abstraction, even though that abstraction is not in the PD path.
Great idea, I'd love to see this implemented somehow. Maybe it even works already?
Currently I just prepend those patches, not intended for public use with an underscore, but this of course doesn't help against name clashes at all.
Ciao
Zitiere "B. Bogart" ben@ekran.org:
Hey all,
Could this method be applied to externals as well?
markex/counter or mex/counter cxc/counter cyclone/counter or cyc/counter
Of course you break all the old patches if you have to use new names, but it provides a facility where you use the object you want rather than
this reminds me of my (long ago) proposal to use "." (a dot) as a separator between library name and external. my implementation (which i posted to the list) was done in pd (and not in the libraries): upon loading the library name was automatically prefixed to the actual object-name, eg "Gem.scale".
of course the "."-separator was just an arbitrary decision and could easily be changed to anything (i was thinking of "::" but "/" might do as well)
everything was transparent to the user, as the original name was kept too. so after loading (e.g.) Gem, there was an object with 2 names (primary) "Gem.scale" and (alias) "scale". after loading cyclone there was an additional "cyclone.scale".
this has been rejected.
markex version you type markex/counter.
the problem arises with multi-named libaries: if i can load Gem both with "-lib Gem" and "-lib gem" (eg. under windos) the scale object will either be called [Gem.scale] or [gem.scale]. this makes patches non-portable.
however, last time we discussed this, there was an idea to introduce library-aliases - either at the command line or at run-time. probably something like "pd -lib cyclone=cyc:zexy:iemlib1=iem:iemlib2=iem"
So there are issues with this method but I think it has potential. Obviously it could use development but I think the concept has some validity. In a way this is creating a seperate namspace for each set of
abstractions/externals. They could also be multiple levels deep:
cvs/markex/counter cvs/cyclone/counter markex/counter cyclone/counter
could be solved by aliases too: "pd -lib /usr/lib/pd/extra/marke=markex:~/cvs/markex/markex=cvs/markex"
as i remember now, the problem with my automatic namespacing was, that calling "pd -lib zexy" and "pd -lib ./zexy" resulted in 2 separate namespaces, e.g [zexy/z~] and [./zexy/z~] which produced non-portable patches. but this could be avoided with aliasing.
Just throught I would throw it out there as fast as it popped into my brain.
Any comments?
mfg.as.dr IOhannes
On Sat, 24 Apr 2004 zmoelnig@iem.at wrote:
Zitiere "B. Bogart" ben@ekran.org:
Hey all,
Could this method be applied to externals as well?
markex/counter or mex/counter cxc/counter cyclone/counter or cyc/counter
Of course you break all the old patches if you have to use new names, but it provides a facility where you use the object you want rather than
this reminds me of my (long ago) proposal to use "." (a dot) as a separator between library name and external.
One of the arguments for using single externals has been that we can structure them exactly in the way Ben suggested. More than that, you have the C++ "using ..." clause for free by adding the path to one of the external collections. Then you can use them without prefix.
Example:
We would have to structure the externals into subfolders of extra ( e.g. .../extra/zexy/makesymbol.pd_xx). If you want to use them directly, just add zexy/extra to your path, call it with makesymbol otherwise load makesymbol with zexy/makesymbol.
For libraries, you can put them into a subfolder (extra/zexy/zexy.pd_xxx) and make soft links from every object in the libray to it. makesymbol.pd_xxx links to zexy.pd_xxx etc...
Not new, but a nice concept that doesn't need code changes. It has been used by Miller with the lrshift~ external too, thats were I got the idea from in the first place.
Guenter
my implementation (which i posted to the list) was done in pd (and not in the libraries): upon loading the library name was automatically prefixed to the actual object-name, eg "Gem.scale".
of course the "."-separator was just an arbitrary decision and could easily be changed to anything (i was thinking of "::" but "/" might do as well)
everything was transparent to the user, as the original name was kept too. so after loading (e.g.) Gem, there was an object with 2 names (primary) "Gem.scale" and (alias) "scale". after loading cyclone there was an additional "cyclone.scale".
this has been rejected.
markex version you type markex/counter.
the problem arises with multi-named libaries: if i can load Gem both with "-lib Gem" and "-lib gem" (eg. under windos) the scale object will either be called [Gem.scale] or [gem.scale]. this makes patches non-portable.
however, last time we discussed this, there was an idea to introduce library-aliases - either at the command line or at run-time. probably something like "pd -lib cyclone=cyc:zexy:iemlib1=iem:iemlib2=iem"
So there are issues with this method but I think it has potential. Obviously it could use development but I think the concept has some validity. In a way this is creating a seperate namspace for each set of
abstractions/externals. They could also be multiple levels deep:
cvs/markex/counter cvs/cyclone/counter markex/counter cyclone/counter
could be solved by aliases too: "pd -lib /usr/lib/pd/extra/marke=markex:~/cvs/markex/markex=cvs/markex"
as i remember now, the problem with my automatic namespacing was, that calling "pd -lib zexy" and "pd -lib ./zexy" resulted in 2 separate namespaces, e.g [zexy/z~] and [./zexy/z~] which produced non-portable patches. but this could be avoided with aliasing.
Just throught I would throw it out there as fast as it popped into my brain.
Any comments?
mfg.as.dr IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
B. Bogart -
Frank Barknecht -
guenter geiger -
zmoelnig＠iem.at