I tried opening a patch that used some of the rradical abstractions and found that in the latest svn snapshot pd-l2ork is based on, import fails to detect rradical (I thought that is what the meta file was supposed to do which is found inside rradical folder). More so, declare also fails to extend the path [declare -stdpath extra/rradical]. Either way ezdac~ (for instance) fails to be created and the only way one can create it is by creating it as rradical/ezdac~. Is this really how things should work in the latest release? If so, what is the purpose of import when practically no lib is built in pd-extended as a lib but rather as a set of objects?
On Thu, 2010-12-16 at 12:51 -0500, Ivica Ico Bukvic wrote:
I tried opening a patch that used some of the rradical abstractions and found that in the latest svn snapshot pd-l2ork is based on, import fails to detect rradical (I thought that is what the meta file was supposed to do which is found inside rradical folder). More so, declare also fails to extend the path [declare -stdpath extra/rradical]. Either way ezdac~ (for instance) fails to be created and the only way one can create it is by creating it as rradical/ezdac~. Is this really how things should work in the latest release? If so, what is the purpose of import when practically no lib is built in pd-extended as a lib but rather as a set of objects?
To add to this, it appears that import fails to "import" directories having abstractions only (rather than libs). You can still "import" individual objects but I guess the latest release is leaning towards moving away from both declare and import in favor of prefixing everything, correct?
Also, is declare deprecated? It has apparently no effect on the search path (at least not here)--even if I declare absolute path it still fails to find anything.
On Thu, Dec 16, 2010 at 6:58 PM, Ivica Ico Bukvic ico@vt.edu wrote:
To add to this, it appears that import fails to "import" directories having abstractions only (rather than libs).
Hi Ivica, for imports my own abstraction directories in my search path I use declare -path dir where dir is the dir I want to import in a relative path. I don't know if it is correct, but it's work. So if I'm wrong please point me to the correct method. cheers husk
On Dec 16, 2010, at 1:08 PM, Husk 00 wrote:
On Thu, Dec 16, 2010 at 6:58 PM, Ivica Ico Bukvic ico@vt.edu wrote:
To add to this, it appears that import fails to "import" directories having abstractions only (rather than libs).
Hi Ivica, for imports my own abstraction directories in my search path I use declare -path dir where dir is the dir I want to import in a relative path. I don't know if it is correct, but it's work. So if I'm wrong please point me to the correct method. cheers husk
For a libdir/folder full of abstractions, these should all work:
[declare -path mylibdir] [import libdir mylibdir] [declare -lib libdir -lib mylibdir]
If you want your folder to be a libdir library, then it just needs to
have a mylibdir/mylibdir-meta.pd file in it, and the libdir.pd_linux
loader needs to be loaded beforehand.
Ico, I think your problem is probably that you don't have the libdir
loader loaded. [declare] and [import] are both here to stay, IMHO.
For l2ork, I think basing your release off of trunk is pretty
hazardous if you want stability. The whole point of copying
everything to a pd-extended release branch in SVN is so that
everything can be tested and bugfixed.
.hc
"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds
Hi Ivica, for imports my own abstraction directories in my search path I use declare -path dir where dir is the dir I want to import in a relative path. I don't know if it is correct, but it's work. So if I'm wrong please point me to the correct method. cheers husk
For a libdir/folder full of abstractions, these should all work:
[declare -path mylibdir] [import libdir mylibdir] [declare -lib libdir -lib mylibdir]
If you want your folder to be a libdir library, then it just needs to
have a mylibdir/mylibdir-meta.pd file in it, and the libdir.pd_linux
loader needs to be loaded beforehand.Ico, I think your problem is probably that you don't have the libdir
loader loaded. [declare] and [import] are both here to stay, IMHO.
For l2ork, I think basing your release off of trunk is pretty
hazardous if you want stability. The whole point of copying
everything to a pd-extended release branch in SVN is so that
everything can be tested and bugfixed.
Ugh, how stupid of me. While testing install of the new release I did make uninstall which effectively deleted my settings file--hence no libdir. My apologies to all for the noise...
Many thanks for helping me regain my sanity :-)
On Thu, 2010-12-16 at 12:58 -0500, Ivica Ico Bukvic wrote:
On Thu, 2010-12-16 at 12:51 -0500, Ivica Ico Bukvic wrote:
I tried opening a patch that used some of the rradical abstractions and found that in the latest svn snapshot pd-l2ork is based on, import fails to detect rradical (I thought that is what the meta file was supposed to do which is found inside rradical folder). More so, declare also fails to extend the path [declare -stdpath extra/rradical]. Either way ezdac~ (for instance) fails to be created and the only way one can create it is by creating it as rradical/ezdac~. Is this really how things should work in the latest release? If so, what is the purpose of import when practically no lib is built in pd-extended as a lib but rather as a set of objects?
To add to this, it appears that import fails to "import" directories having abstractions only (rather than libs). You can still "import" individual objects but I guess the latest release is leaning towards moving away from both declare and import in favor of prefixing everything, correct?
I don't know, but I am pretty sure that both [import] and [declare] are still heavily in use. I don't know of any plans to get rid of those.
Also, I'd find pd-l2ork quite unusable without [declare]. [declare] is the vanilla way of loading paths and libs and is the smallest denominator, that should work everywhere (i.e in all Pd flavours).
Also, is declare deprecated? It has apparently no effect on the search path (at least not here)--even if I declare absolute path it still fails to find anything.
It's working at least in Pd-extended (0.42.6) ,Pd (0.42.6) and Pd-0.43.
Roman
-
Hans-Christoph Steiner -
Husk 00 -
Ivica Ico Bukvic -
Roman Haefeli