Hi, some libraries (Gem, pdp...) use abstractions. I wonder if their paths should be included in the startup paths in pd extended. Or if one should create objects with the "Gem" prefix (for example Gem/pix_blobtracker). the problem with some abstractions is, that they have also a help patch. and rightclick - help then opens the abstraction and not the help patch (if the path is included in the default paths). otoh, many helppatches and abstractions do not work without the paths given, because they have no prefix... marius.
Hallo!
some libraries (Gem, pdp...) use abstractions. I wonder if their paths should be included in the startup paths in pd extended. Or if one should
that should not be needed - normally it should, because all the abstractions and externals of a library should be in one directory (e.g. externals/zexy) - but Gem is still compiled as single file external, so it can be that it doesn't work with it ...
create objects with the "Gem" prefix (for example Gem/pix_blobtracker). the problem with some abstractions is, that they have also a help patch. and rightclick - help then opens the abstraction and not the help patch (if the path is included in the default paths). otoh, many helppatches and abstractions do not work without the paths given, because they have no prefix...
Which version do you use ? In the latest autobuilds the help patches are in the same directory as the objects itself, so it should work ! (also without including the path)
LG Georg
Perhaps these should be their own libdirs like "gemabs" and "pdpabs".
.hc
On May 3, 2007, at 10:24 PM, marius schebella wrote:
Hi, some libraries (Gem, pdp...) use abstractions. I wonder if their paths should be included in the startup paths in pd extended. Or if one
should create objects with the "Gem" prefix (for example Gem/ pix_blobtracker). the problem with some abstractions is, that they have also a help
patch. and rightclick - help then opens the abstraction and not the help
patch (if the path is included in the default paths). otoh, many helppatches and abstractions do not work without the paths given, because they
have no prefix... marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
Hans-Christoph Steiner wrote:
Perhaps these should be their own libdirs like "gemabs" and "pdpabs".
what's wrong with having abstractions in the same directory as the binary?
e.g. extra/Gem/Gem.pd_linux extra/Gem/hsv2rgb.pd
imho ideally, [import Gem] would find .../Gem/Gem.pd_linux and then add .../Gem/ to the search paths.
(might well be that this is already the case, i don't know)
mfg.asdr IOhannes
Hallo!
what's wrong with having abstractions in the same directory as the binary?
Yes, I also think that should be the way - as it's also working like this with all the other externals ...
e.g. extra/Gem/Gem.pd_linux extra/Gem/hsv2rgb.pd
imho ideally, [import Gem] would find .../Gem/Gem.pd_linux and then add .../Gem/ to the search paths.
(might well be that this is already the case, i don't know)
AFAIK it does not work yet - but it should not be that hard to implement ...
LG Georg
On May 4, 2007, at 2:50 PM, Georg Holzmann wrote:
Hallo!
what's wrong with having abstractions in the same directory as the
binary?Yes, I also think that should be the way - as it's also working
like this with all the other externals ...e.g. extra/Gem/Gem.pd_linux extra/Gem/hsv2rgb.pd imho ideally, [import Gem] would find .../Gem/Gem.pd_linux and
then add .../Gem/ to the search paths. (might well be that this is already the case, i don't know)AFAIK it does not work yet - but it should not be that hard to
implement ...
That does not work and would be a pain to implement.
I think that there should just be a libdir called "gemabs" for those
pd patches. If Gem was compiled as single-file-single-class, then
this would "just work".
.hc
LG Georg
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Hans-Christoph Steiner wrote:
AFAIK it does not work yet - but it should not be that hard to implement ...
That does not work and would be a pain to implement.
why?
I think that there should just be a libdir called "gemabs" for those pd patches. If Gem was compiled as single-file-single-class, then this would "just work".
since Gem objects do share a lot of code, even splitting Gem into a lot of separate objects (which is planned on the long term) will still need a "core" which i would implement as a (very small) Gem.pd_linux
mfgasr IOhannes
On May 4, 2007, at 3:46 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
AFAIK it does not work yet - but it should not be that hard to implement ...
That does not work and would be a pain to implement.
why?
I think that there should just be a libdir called "gemabs" for
those pd patches. If Gem was compiled as single-file-single-class, then this would "just work".since Gem objects do share a lot of code, even splitting Gem into a
lot of separate objects (which is planned on the long term) will still
need a "core" which i would implement as a (very small) Gem.pd_linux
I think that the way that Thomas did it with flext makes a lot of
sense. He made a flext.so and had the objects link to that DLL.
That should work fine with Gem. It could be something like libgem.so/
libgem.dylib/libgem.dll
.hc
mfgasr IOhannes
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
On May 4, 2007, at 3:46 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
AFAIK it does not work yet - but it should not be that hard to implement ...
That does not work and would be a pain to implement.
why?
I think that there should just be a libdir called "gemabs" for those pd patches. If Gem was compiled as single-file-single-class, then this would "just work".
since Gem objects do share a lot of code, even splitting Gem into a lot of separate objects (which is planned on the long term) will still need a "core" which i would implement as a (very small) Gem.pd_linux
I think that the way that Thomas did it with flext makes a lot of sense. He made a flext.so and had the objects link to that DLL. That should work fine with Gem. It could be something like libgem.so/libgem.dylib/libgem.dll
this is just another option. still it does not answer the question "why does it not work and why would it be a pain to implement?"
ma. IOhannes
-
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
marius schebella