I have been thinking that it would be handy to have the abstractions collection all in one folder so that it could be added to the path. This would be useful for abstractions that are generally useful. It probably makes sense to arrange this the same way the externals are arranged: directory for each dev, then when compiled, all of the abstractions are put into on directory, which is added to the path.
Thoughts? Objections?
.hc
Hi,
Hans-Christoph Steiner hans@eds.org wrote:
I have been thinking that it would be handy to have the abstractions collection all in one folder so that it could be added to the path. This would be useful for abstractions that are generally useful. It probably makes sense to arrange this the same way the externals are arranged: directory for each dev, then when compiled, all of the abstractions are put into on directory, which is added to the path.
Abstractions surely will create another problem with dupe names. I'm not sure if putting them all into one directory will make things easier here, as probably everyone has abstractions of his/her own and thus you can never know which name is already taken. That's why I would rather see it, if abstractions are not "installed" in another way than by adding some paths to the pdrc.
One thing that would be very useful though could be wildcard path expansion. For example I organized my rradical collection so that it uses several paths:
rradical/instruments rradical/effects rradical/control rradical/...
It would be nice to be able to add them all to pdrc with something like "-path /usr/lib/pd/rradical/*/" or even "-path /usr/lib/pd/rradical/[^test]/" to include all subdirs except "test"
This also would allow us to make a pdrc easier to write with the CVS while still retaining some structure.
ciao -- Frank Barknecht _ ___footils.org_
On Wednesday, Mar 17, 2004, at 11:09 America/New_York, Frank Barknecht wrote:
Hi,
Hans-Christoph Steiner hans@eds.org wrote:
I have been thinking that it would be handy to have the abstractions collection all in one folder so that it could be added to the path. This would be useful for abstractions that are generally useful. It probably makes sense to arrange this the same way the externals are arranged: directory for each dev, then when compiled, all of the abstractions are put into on directory, which is added to the path.
Abstractions surely will create another problem with dupe names. I'm not sure if putting them all into one directory will make things easier here, as probably everyone has abstractions of his/her own and thus you can never know which name is already taken. That's why I would rather see it, if abstractions are not "installed" in another way than by adding some paths to the pdrc.
I am not suggesting that all abstractions be put into this single directory, just abstractions that are meant to be used like standard objects. For example, I have a [debug-print] abstraction that would be generally useful. Yes, these abstractions will occupy the same namespace, but that is inevitable. For abstractions that make up a distinct system, like rradical, it would probably make sense to keep them separate. That reminds me, when will rradical join the cvs?
One thing that would be very useful though could be wildcard path expansion. For example I organized my rradical collection so that it uses several paths:
rradical/instruments rradical/effects rradical/control rradical/...
It would be nice to be able to add them all to pdrc with something like "-path /usr/lib/pd/rradical/*/" or even "-path /usr/lib/pd/rradical/[^test]/" to include all subdirs except "test"
This would be handy. While we are at it, it would be nice to add comments to .pdrc files, and also support them on Windows.
This also would allow us to make a pdrc easier to write with the CVS while still retaining some structure.
Relati
ciao
Frank Barknecht _ ___footils.org_
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
That reminds me, when will rradical join the cvs?
Soon. I will present rradical at the LAConf2 in Karlsruhe, and I'd like to have it in the CVS before that. Actually I'm quite happy with the basic structure now, which so far could handle every problem I could throw at it.
Now there will be a bit more documentation to do and especially lots of patches which make the system more complete.
ciao
-
Frank Barknecht -
Hans-Christoph Steiner