Hallo,
why is it, that to be able to simply read the help file for "center_point" in "mapping" I have to add four (4!) paths to my .pdrc or the command line?
Here are the paths I need to set and their reasons:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin]
- SVN/abstractions/ - to find [purepd/float_argument], [purepd/purepd_error] and [purepd/once]
- SVN/abstractions/purepd - to find [float_argument]
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong? Try this:
- create a single place to store externals, I recommend ~/pd-externals/
- add it to your path
- cd /path/to/pure-data/trunk/abstractions/
- cp -a purepd ~/pd-externals
(mapping is still poorly organized in SVN, so its a bit harder)
- cd /path/to/pure-data/trunk/externals/mapping
- mkdir ~/pd-externals/mapping
- cp -a *.pd ~/pd-externals/mapping
- cd help
- cp -a *-help.pd ~/pd-externals/mapping
- touch ~/pd-externals/mapping/mapping-meta.pd
That's it. Then if you have the libdir.pd_linux loader loaded, you
can also load that as a lib using any of the standard methods.
(you'll need the libdir.c from SVN).
pd -lib libdir -lib mapping declare -lib mapping import mapping
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hans-Christoph Steiner a écrit :
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong?
no, because mapping is doing it wrong. i'm more and more convinced that the only way i now have to use the object that i write is to fork this lib. it's a bad solution for everybody, but at last i'll be able to profit from my work.
Cyrille
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong?
I'm not doing it wrong, it works fine.
But because mapping is sometimes using prefixes internally, sometimes not (you get [float_argument] and [purepd/float_argument] or [reverse] and [mapping/reverse]) this results in users having to add twice the amount of paths or imports.
Ciao
Frank
On Apr 6, 2009, at 11:26 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong?
I'm not doing it wrong, it works fine.
But because mapping is sometimes using prefixes internally,
sometimes not (you get [float_argument] and [purepd/float_argument] or [reverse] and [mapping/reverse]) this results in users having to add twice the
amount of paths or imports.
Inside of the objects themselves, I use always the [mapping/reverse]
form. Only in the help patches do I use the [reverse] form. That
convention seemed to make sense at the time, but I am not married to it.
.hc
Ciao
Frank
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 a écrit :
Inside of the objects themselves, I use always the [mapping/reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it.
since all mapping object are in the same directory, using the [reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation.
do you agree if i change this?
Cyrille
On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
Inside of the objects themselves, I use always the [mapping/ reverse] form. Only in the help patches do I use the [reverse]
form. That convention seemed to make sense at the time, but I am
not married to it.since all mapping object are in the same directory, using the
[reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able
to move the objects / copy them in your patch directory ). So i see
this as a big improvement of the situation.do you agree if i change this?
Unfortunately, that's not entirely true, otherwise I would say to
change it. Right now, a binary object will trump ANY abstraction,
even if it is in the same directory. So if someone loads a binary
object called "reverse", then [reverse] will ALWAYS be that binary, so
matter where you put reverse.pd or how you load it. [mapping/reverse]
prevents that.
This is a perfect case of why we should change the load order in Pd.
I think it should search for all object types in a given path
(i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next
path. Currently the opposite happens: it searches .pd_linux in all
paths, then the loaders (i.e. .pd_lua) in all paths, then the
abstractions in all paths.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner a écrit :
On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
Inside of the objects themselves, I use always the [mapping/reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it.
since all mapping object are in the same directory, using the
[reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation.do you agree if i change this?
Unfortunately, that's not entirely true, otherwise I would say to change it. Right now, a binary object will trump ANY abstraction, even if it is in the same directory. So if someone loads a binary object called "reverse", then [reverse] will ALWAYS be that binary, so matter where you put reverse.pd or how you load it. [mapping/reverse] prevents that.
name clash are bad. curently it's a fact. things may change in the future, but now nameclash must be avoid.
since there already are nameclash, it's important for a user to have a full control of the object used. i do this by copying abstraction in my patch folder. it also allow my patch to work latter, when the abstraction have changed.
This is a perfect case of why we should change the load order in Pd.
ok. change it if you wish. but don't find workaround with solution that work only for you.
sorry if i'm rude, but i'm more and more irritated by this problem. c
I think it should search for all object types in a given path (i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next path.
Currently the opposite happens: it searches .pd_linux in all paths, then the loaders (i.e. .pd_lua) in all paths, then the abstractions in all paths..hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Apr 9, 2009, at 2:33 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
Inside of the objects themselves, I use always the [mapping/ reverse] form. Only in the help patches do I use the [reverse]
form. That convention seemed to make sense at the time, but I am
not married to it.since all mapping object are in the same directory, using the
[reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be
able to move the objects / copy them in your patch directory ). So
i see this as a big improvement of the situation.do you agree if i change this?
Unfortunately, that's not entirely true, otherwise I would say to
change it. Right now, a binary object will trump ANY abstraction,
even if it is in the same directory. So if someone loads a binary
object called "reverse", then [reverse] will ALWAYS be that binary,
so matter where you put reverse.pd or how you load it. [mapping/ reverse] prevents that.name clash are bad. curently it's a fact. things may change in the future, but now nameclash must be avoid.
since there already are nameclash, it's important for a user to have
a full control of the object used. i do this by copying abstraction in my patch folder. it also allow my patch to work latter, when the abstraction have
changed.
Copying the abstraction into the same folder as the project will not
prevent the problem I described above. As things are, that's not a
solution. I think it'll work most of time, like most of these methods
we discuss back and forth.
The namespace prefix like [mapping/reverse] is also not infallable,
but it is a lot less likely to be affected by nameclashes, since there
would have to be both a folder and a file named the same. It seems to
me a good starting place. In any case, nameclashes are an old issue,
many people have tackled it, I think we can learn from them and make a
Pd-ish implementation of namespaces/import that is not complicated.
I think we can make a solution that always works. I am not satisfied
with just using the current situation. I've been burned too many
times in projects and while teaching workshops and classes by name
conflicts. The output~ one is a recent example.
.hc
This is a perfect case of why we should change the load order in Pd.
ok. change it if you wish. but don't find workaround with solution that
work only for you.sorry if i'm rude, but i'm more and more irritated by this problem. c
I think it should search for all object types in a given path
(i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next
path. Currently the opposite happens: it searches .pd_linux in all
paths, then the loaders (i.e. .pd_lua) in all paths, then the
abstractions in all paths. .hc ---------------------------------------------------------------------------- "[W ]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hey List.
not wanting to offend anybody. But this has some good amount of
absurdity in it, i think.
And for any Newbie following that its actually quite frightening.
Frank calls his way of doing "hell" and it only includes 3 steps. And Hans Christoph calls his way "easy" and it includes 10 steps ....
.... monster monster-hell......
Another thing i always found strange about tthe mapping-collection. If
you want to use the helpfiles
in one of your patches and actually use more then one you get into
conflicts
What needs to be done to restructure mapping ?? I could help maybe,
because its a library i used very often and found
it very useful. I would be happy to do something good to that
library ;-)
All the Best
Luigi
Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner:
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong? Try this:
- create a single place to store externals, I recommend ~/pd-
externals/ 2. add it to your path 3. cd /path/to/pure-data/trunk/abstractions/ 4. cp -a purepd ~/pd-externals
(mapping is still poorly organized in SVN, so its a bit harder)
- cd /path/to/pure-data/trunk/externals/mapping
- mkdir ~/pd-externals/mapping
- cp -a *.pd ~/pd-externals/mapping
- cd help
- cp -a *-help.pd ~/pd-externals/mapping
- touch ~/pd-externals/mapping/mapping-meta.pd
That's it. Then if you have the libdir.pd_linux loader loaded, you
can also load that as a lib using any of the standard methods.
(you'll need the libdir.c from SVN).pd -lib libdir -lib mapping declare -lib mapping import mapping
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Luigi a écrit :
Hey List. not wanting to offend anybody. But this has some good amount of absurdity in it, i think. And for any Newbie following that its actually quite frightening.
Frank calls his way of doing "hell" and it only includes 3 steps.
it's not the steps the problem, the problem come from what is imply by this step.
And Hans Christoph calls his way "easy" and it includes 10 steps ....
;-)
.... monster monster-hell......
Another thing i always found strange about tthe mapping-collection. If you want to use the helpfiles in one of your patches and actually use more then one you get into conflicts
i don't understand what you want to do, can you elaborate?
What needs to be done to restructure mapping ?? I could help maybe, because its a library i used very often and found it very useful. I would be happy to do something good to that library ;-)
the problem is not human resource for restructuring this lib.
it's just that Franck and I did not share the same way of thinking than hans.
Cyrille
All the Best
Luigi
Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner:
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong? Try this:
- create a single place to store externals, I recommend ~/pd-externals/
- add it to your path
- cd /path/to/pure-data/trunk/abstractions/
- cp -a purepd ~/pd-externals
(mapping is still poorly organized in SVN, so its a bit harder)
- cd /path/to/pure-data/trunk/externals/mapping
- mkdir ~/pd-externals/mapping
- cp -a *.pd ~/pd-externals/mapping
- cd help
- cp -a *-help.pd ~/pd-externals/mapping
- touch ~/pd-externals/mapping/mapping-meta.pd
That's it. Then if you have the libdir.pd_linux loader loaded, you can also load that as a lib using any of the standard methods.
(you'll need the libdir.c from SVN).pd -lib libdir -lib mapping declare -lib mapping import mapping
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
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
Yes, there is some absurdity to this conversation. I guess Frank and
I have been doing this for so long, its just part of a game we play ;-)
Anyway, I could give the instructions in one step:
- use Pd-extended ;-)
I don't think many newbies really want to get into the nitty-gritty of
hand-built Pd installs, but this conversation did make me smooth out
the installation process. Before, the 10 steps were for creating a
library from scratch. I think its pretty simple considering. Now,
the libraries are pre-built in SVN, so you only need to:
- cd /path/to/your/extra (or wherever you want to install stuff)
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mappin...
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/pur...
- pd -lib libdir -lib purepd -lib mapping
If that doesn't work for you, there is a bug. That has been working
with Pd-extended for some years now. As for issues with this setup,
please elaborate on them so we can fix things.
.hc
On Apr 6, 2009, at 10:37 AM, Luigi wrote:
Hey List. not wanting to offend anybody. But this has some good amount of
absurdity in it, i think. And for any Newbie following that its actually quite frightening.Frank calls his way of doing "hell" and it only includes 3 steps. And Hans Christoph calls his way "easy" and it includes 10 steps ....
.... monster monster-hell......
Another thing i always found strange about tthe mapping-collection.
If you want to use the helpfiles in one of your patches and actually use more then one you get into
conflictsWhat needs to be done to restructure mapping ?? I could help maybe,
because its a library i used very often and found it very useful. I would be happy to do something good to that
library ;-)All the Best
Luigi
Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner:
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
- SVN/externals - otherwise [center_point] isn't found
- SVN/externals/mapping - to find [mapping/reverse] and
[mapping/disjoin]
These two were meant to have reversed reasons.
Hmm, because you are doing it wrong? Try this:
- create a single place to store externals, I recommend ~/pd-
externals/ 2. add it to your path 3. cd /path/to/pure-data/trunk/abstractions/ 4. cp -a purepd ~/pd-externals
(mapping is still poorly organized in SVN, so its a bit harder)
- cd /path/to/pure-data/trunk/externals/mapping
- mkdir ~/pd-externals/mapping
- cp -a *.pd ~/pd-externals/mapping
- cd help
- cp -a *-help.pd ~/pd-externals/mapping
- touch ~/pd-externals/mapping/mapping-meta.pd
That's it. Then if you have the libdir.pd_linux loader loaded, you
can also load that as a lib using any of the standard methods.
(you'll need the libdir.c from SVN).pd -lib libdir -lib mapping declare -lib mapping import mapping
.hc
As we enjoy great advantages from inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. - Benjamin
Franklin
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
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-)
Anyway, I could give the instructions in one step:
- use Pd-extended ;-)
But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions.
I don't think many newbies really want to get into the nitty-gritty of
hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to:
- cd /path/to/your/extra (or wherever you want to install stuff)
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mappin...
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/pur...
- pd -lib libdir -lib purepd -lib mapping
You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail.
Ciao
Frank
On Apr 8, 2009, at 1:18 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yes, there is some absurdity to this conversation. I guess Frank
and I have been doing this for so long, its just part of a game we play ;-)Anyway, I could give the instructions in one step:
- use Pd-extended ;-)
But that's exactly what I mean: "mapping" IMO has become promotion
material for pd-extended, but increasingly hard to use for users of newer Pd
versions or alternative distributions.I don't think many newbies really want to get into the nitty-gritty
of hand-built Pd installs, but this conversation did make me smooth
out the installation process. Before, the 10 steps were for creating a
library from scratch. I think its pretty simple considering. Now, the
libraries are pre-built in SVN, so you only need to:
- cd /path/to/your/extra (or wherever you want to install stuff)
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mappin...
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/pur...
- pd -lib libdir -lib purepd -lib mapping
You cheat a bit here: "svn co whereverlibdiris; make libdir", and I
don't know, if help-files in mapping work then - with just your sets they won't.
And you still have the requirement of putting the directories mapping and
purepd into a directory in the pd path like "extra", so it's still four paths to
set, just like I wrote in my first mail.
How about checking whether help files work before reporting the
problem? You only need to install libdir once. Plus if you use the
latest version of libdir, then 'extra' can be any folder in the path.
I suggest one of these:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with...
.hc
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
On Apr 8, 2009, at 1:28 AM, Hans-Christoph Steiner wrote:
On Apr 8, 2009, at 1:18 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yes, there is some absurdity to this conversation. I guess Frank
and I have been doing this for so long, its just part of a game we
play ;-)Anyway, I could give the instructions in one step:
- use Pd-extended ;-)
But that's exactly what I mean: "mapping" IMO has become promotion
material for pd-extended, but increasingly hard to use for users of newer Pd
versions or alternative distributions.I don't think many newbies really want to get into the nitty- gritty of hand-built Pd installs, but this conversation did make me smooth
out the installation process. Before, the 10 steps were for creating a
library from scratch. I think its pretty simple considering. Now, the
libraries are pre-built in SVN, so you only need to:
- cd /path/to/your/extra (or wherever you want to install stuff)
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mappin...
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/pur...
- pd -lib libdir -lib purepd -lib mapping
You cheat a bit here: "svn co whereverlibdiris; make libdir", and I
don't know, if help-files in mapping work then - with just your sets they
won't. And you still have the requirement of putting the directories mapping and
purepd into a directory in the pd path like "extra", so it's still four paths to
set, just like I wrote in my first mail.How about checking whether help files work before reporting the
problem? You only need to install libdir once. Plus if you use the
latest version of libdir, then 'extra' can be any folder in the
path. I suggest one of these:http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with...
Oops, forgot the link to the libdir binary, no compiling necessary.
Its the older one, so that still requires installing into 'extra', I
am working on a new release:
http://at.or.at/hans/pd/objects.html#libdir
.hc
.hc
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you
can hear it, you can have it. - Dizzy Gillespie
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail.
How about checking whether help files work before reporting the problem?
I wrote "I don't know if helpp-files work" - but I've tried it now.
You only need to install libdir once. Plus if you use the latest version of libdir, then 'extra' can be any folder in the path. I suggest one of these:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with...
Okay, here's what I did:
$ cp -a SVN/mapping /usr/lib/pd/extra $ cd SVN/loaders $ svn update $ make (to make libdir.pd_linux) $ pd -lib libdir -lib mapping
gives this: ... libdir loader $Revision: 1.8 $ compiled on Apr 8 2009 at 07:46:59 compiled against Pd version 0.42.4. mapping: can't load library ...
and I still cannot create any mapping object. I was able to fix that by adding a mapping-meta.pd file manually (copied from some pd-extended source on my disk, could find one in SVN's trunk). Help files still don't work.
According to http://puredata.info/docs/developer/Libdir help-files have to be either in 5.reference/libname or next to the object in question. Both is not the case the way mapping is laid out and again something, that has to be done manually.
That's all pretty complicated for a newbie like me. :)
Ciao
Frank
On Apr 8, 2009, at 1:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
You cheat a bit here: "svn co whereverlibdiris; make libdir", and
I don't know, if help-files in mapping work then - with just your sets
they won't. And you still have the requirement of putting the directories
mapping and purepd into a directory in the pd path like "extra", so it's still
four paths to set, just like I wrote in my first mail.How about checking whether help files work before reporting the
problem?I wrote "I don't know if helpp-files work" - but I've tried it now.
You only need to install libdir once. Plus if you use the latest
version of libdir, then 'extra' can be any folder in the path. I suggest
one of these:http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with...
Okay, here's what I did:
$ cp -a SVN/mapping /usr/lib/pd/extra $ cd SVN/loaders $ svn update $ make (to make libdir.pd_linux) $ pd -lib libdir -lib mapping
gives this: ... libdir loader $Revision: 1.8 $ compiled on Apr 8 2009 at 07:46:59 compiled against Pd version 0.42.4. mapping: can't load library ...
and I still cannot create any mapping object. I was able to fix that
by adding a mapping-meta.pd file manually (copied from some pd-extended source
on my disk, could find one in SVN's trunk). Help files still don't work.According to http://puredata.info/docs/developer/Libdir help-files
have to be either in 5.reference/libname or next to the object in question.
Both is not the case the way mapping is laid out and again something, that has
to be done manually.That's all pretty complicated for a newbie like me. :)
Luckily the solution is simple: "svn update". Sounds like you are
working with an old copy. The folder "externals/mapping/help" should
be gone, all the help patches in "externals/mapping", and there should
be a "externals/mapping/mapping-meta.pd" file. Otherwise, you're
working with old code.
.hc
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Luckily the solution is simple: "svn update". Sounds like you are
working with an old copy. The folder "externals/mapping/help" should be gone, all the help patches in "externals/mapping", and there should be a "externals/mapping/mapping-meta.pd" file. Otherwise, you're working with old code.
Ah, indeed, I was using the wrong outdated copy, so sorry for the wrong help-file noise.
Ciao
Frank
Frank Barknecht a écrit :
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-)
Anyway, I could give the instructions in one step:
- use Pd-extended ;-)
But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions.
specially since it's mainly abstraction, i don't understand why we need to install it. i think for this specific lib, any dependency of object outside it's directory can be seen as a bug.
c
I don't think many newbies really want to get into the nitty-gritty of
hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to:
- cd /path/to/your/extra (or wherever you want to install stuff)
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mappin...
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/pur...
- pd -lib libdir -lib purepd -lib mapping
You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail.
Ciao
On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:
Frank Barknecht a écrit :
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yes, there is some absurdity to this conversation. I guess Frank
and I have been doing this for so long, its just part of a game we
play ;-)Anyway, I could give the instructions in one step:
- use Pd-extended ;-)
But that's exactly what I mean: "mapping" IMO has become promotion
material for pd-extended, but increasingly hard to use for users of newer Pd
versions or alternative distributions.specially since it's mainly abstraction, i don't understand why we
need to install it. i think for this specific lib, any dependency of object outside it's
directory can be seen as a bug.
I don't understand this at all. Why did every modern operating system
spend massive amounts of work to switch from static linking of
libraries (i.e. including the library with the program itself) to
dynamic, shared libraries (i.e. a single copy of a library shared by
all programs that use it)?
.hc
c
I don't think many newbies really want to get into the nitty- gritty of hand-built Pd installs, but this conversation did make
me smooth out the installation process. Before, the 10 steps were
for creating a library from scratch. I think its pretty simple
considering. Now, the libraries are pre-built in SVN, so you only
need to:
- cd /path/to/your/extra (or wherever you want to install stuff)
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mappin...
- svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/pur...
- pd -lib libdir -lib purepd -lib mapping
You cheat a bit here: "svn co whereverlibdiris; make libdir", and I
don't know, if help-files in mapping work then - with just your sets they
won't. And you still have the requirement of putting the directories mapping and
purepd into a directory in the pd path like "extra", so it's still four paths to
set, just like I wrote in my first mail. Ciao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:
i think for this specific lib, any dependency of object outside it's
directory can be seen as a bug.I don't understand this at all. Why did every modern operating system
spend massive amounts of work to switch from static linking of libraries (i.e. including the library with the program itself) to dynamic, shared libraries (i.e. a single copy of a library shared by all programs that use it)?
I think, advantages and disadvantages have to be weighted, and IMO mapping currently is leaning to a not very user friendly side. For example its use of [float_argument], [symbol_argument] and [once] from purepd creates a dependency on purepd that is completely unnecessary: [once] is only used once, [symbol_argument] also, and float_argument very often is used where a simple [f $1] would be enough (its second argument is empty). So I'd say, get rid of it and be more friendly to users.
Another case is the "standardization" to use abstraction names, that require the (sometimes broken) hexloader: Life would be much easier for a lot of people without the "->" convention.
Other cases may not be so easy to fix and some externals are hard to replace, but as it currenly is, mapping looks like a collection that puts some abstract design principles higher than actual user demands. Of course that's just my humble opinion, which is leaning to a much more simplistic side.
Ciao
Frank
On Apr 8, 2009, at 3:23 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:
i think for this specific lib, any dependency of object outside it's directory can be seen as a bug.
I don't understand this at all. Why did every modern operating
system spend massive amounts of work to switch from static linking of
libraries (i.e. including the library with the program itself) to dynamic,
shared libraries (i.e. a single copy of a library shared by all programs
that use it)?I think, advantages and disadvantages have to be weighted, and IMO
mapping currently is leaning to a not very user friendly side. For example
its use of [float_argument], [symbol_argument] and [once] from purepd creates a
dependency on purepd that is completely unnecessary: [once] is only used once, [symbol_argument] also, and float_argument very often is used where
a simple [f $1] would be enough (its second argument is empty). So I'd say, get
rid of it and be more friendly to users.
If there is good code out there, I want to use it, not reinvent it.
If you use mapping in Pd-extended, you never need to know anything
about what's happening inside, it just works. With a little bit of
effort, Pd-vanilla users can also acheive this. That's why I am
fixing up libdir.c and these libraries in SVN.
Another case is the "standardization" to use abstraction names, that
require the (sometimes broken) hexloader: Life would be much easier for a
lot of people without the "->" convention.
Indeed, I fully agree. That's why I fixed it over a year ago :D
mapping needs to hexloader tricks.
Other cases may not be so easy to fix and some externals are hard to
replace, but as it currenly is, mapping looks like a collection that puts
some abstract design principles higher than actual user demands. Of course that's
just my humble opinion, which is leaning to a much more simplistic side.
These libraries were a place for me to experiment with ways of
handling libraries in Pd easier. Some of the experiments failed, but
I think right now its in a pretty good place. So try it out the way
it is now and tell me what doesn't work.
.hc
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
Hans-Christoph Steiner a écrit : ...
If there is good code out there, I want to use it, not reinvent it.
having a complex abstraction to replace this :
loadbang $1 moses 0
is overkill. it add complexity to a simple patch.
If you use mapping in Pd-extended, you never need to know anything about what's happening inside, it just works.
if you don't use pd extended, it just don't work. i already explain why i don't use pd-extended, and will not change my mind soon.
With a little bit of effort, Pd-vanilla users can also acheive this. That's why I am fixing up libdir.c and these libraries in SVN.
i just don't want to add complexity to a simple thing, just because you think it's better.
These libraries were a place for me to experiment with ways of handling libraries in Pd easier.
for me it was something for everyday use! and i basically can't use it the way i want, and the way i made it.
Some of the experiments failed, but I think right now its in a pretty good place. So try it out the way it is now and tell me what doesn't work.
to have mapping/reverse in the object break the way i work with pd for the last 8 years.
to use [float_argument] that is outside the mapping folder cause problem to. (remember the pm mapping presentation @ hangar?) at least, it could be copy / linked on the mapping directory. the best would be of course to replace it with a more simpler code based on 3 simple object. (well, to revert the change you made to my objects)
this are the biggest problem i've got.
cyrille
moses 0 filter also negative arguments, they usually are unwanted. but of course sel 0 is used the rest of the time.
c
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
Hans-Christoph Steiner a écrit : ...
If there is good code out there, I want to use it, not reinvent it.
having a complex abstraction to replace this : loadbang $1 moses 0
shouldn't that be [select 0] rather than [moses 0] ?
mfgasd.r IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
cyrille henry -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luigi