Hi, for any reason the flatspace externals are not created by only using the objectname. for example mass2D. it is created when I type flatspace/mass2D. however, it is also not possible to add flatspace to the startup paths, at least that does not solve the problem. any idea, what I could do? pd-extended-0.39.2-RC2, osx. marius.
Hallo Marius!
for any reason the flatspace externals are not created by only using the objectname. for example mass2D. it is created when I type flatspace/mass2D. however, it is also not possible to add flatspace to the startup paths, at least that does not solve the problem. any idea, what I could do? pd-extended-0.39.2-RC2, osx.
If this is the new pd-extended version you have to load the libdir loader first:
pd -lib libdir
and then you can load all the other libraries (e.g. flatspace).
LG Georg
libdir: can't load library. uidohotswos. will look at that later... thnx. marius.
Georg Holzmann wrote:
Hallo Marius!
for any reason the flatspace externals are not created by only using the objectname. for example mass2D. it is created when I type flatspace/mass2D. however, it is also not possible to add flatspace to the startup paths, at least that does not solve the problem. any idea, what I could do? pd-extended-0.39.2-RC2, osx.
If this is the new pd-extended version you have to load the libdir loader first:
pd -lib libdir
and then you can load all the other libraries (e.g. flatspace).
LG Georg
ok found the problem. I did not exchange the preferences file. so all the paths were still set to test7. but acually that is a problem, because I add a lot of my own paths and I don't want to add them everytime when I change the pd version. is it possible to use additional preferences files? hmm, I think I will add them all at the "startup flags" line. So, the paths are working now and I don't need libdir for it to work (libdir itself still doesnot load). marius.
Georg Holzmann wrote:
Hallo!
libdir: can't load library. uidohotswos.
jodesiswor ;)
However, can you try pd -verbose and see what happens ?
LG Georg
Hallo!
ok found the problem. I did not exchange the preferences file. so all the paths were still set to test7. but acually that is a problem, because I add a lot of my own paths and I don't want to add them everytime when I change the pd version. is it possible to use additional preferences files? hmm, I think I will add them all at the "startup flags" line.
hm ... the idea behind the libdir stuff is (at least for me), that you don't need the startup flags and preference files ... You simply import your library with [import your_lib] directly within the patch - however, you should be still able to use the preference file and etc.
So, the paths are working now and I don't need libdir for it to work (libdir itself still doesnot load). marius.
Sorry - I think my suggestions were wrong, because you still use the old version (0.39) and not the ones from the autobuilds ...
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
hm ... the idea behind the libdir stuff is (at least for me), that you don't need the startup flags and preference files ... You simply import your library with [import your_lib] directly within the patch - however, you should be still able to use the preference file and etc.
Can I do "import import"?
Just joking, but as far as I understand patches using "import" need at least one preference line (unless you have import.pd_linux already in the default path) and one external.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo!
Can I do "import import"?
Just joking, but as far as I understand patches using "import" need at least one preference line (unless you have import.pd_linux already in the default path) and one external.
Of course ... but import is in the default path (in latest extended).
LG Georg
On May 2, 2007, at 12:44 PM, Frank Barknecht wrote:
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
hm ... the idea behind the libdir stuff is (at least for me), that
you don't need the startup flags and preference files ... You simply import your library with [import your_lib] directly within the patch - however, you should be still able to use the
preference file and etc.Can I do "import import"?
Just joking, but as far as I understand patches using "import" need at least one preference line (unless you have import.pd_linux already in the default path) and one external.
The idea is to strip down Pd to the most basic objects, then make
everything else a library that's included when needed. [import] and/
or [declare] seem to be some of the essential few.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The idea is to strip down Pd to the most basic objects, then make
everything else a library that's included when needed. [import] and/ or [declare] seem to be some of the essential few.
I wonder: How should we deal with the thousands of abstractions that have been created in the ten years since Pd was invented? To avoid having to rewrite every patch, some kind of central path preference mechanism still will be necessary, I guess.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo!
I wonder: How should we deal with the thousands of abstractions that have been created in the ten years since Pd was invented? To avoid having to rewrite every patch, some kind of central path preference mechanism still will be necessary, I guess.
hm ... how do you mean that ?
They can be included in the libdir format (and are already) - e.g. you only have to place a [import listabs] in the patch ... (like in the most programming languages)
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
I wonder: How should we deal with the thousands of abstractions that have been created in the ten years since Pd was invented? To avoid having to rewrite every patch, some kind of central path preference mechanism still will be necessary, I guess.
hm ... how do you mean that ?
They can be included in the libdir format (and are already) - e.g. you only have to place a [import listabs] in the patch ... (like in the most programming languages)
No, I mean the other way around: What about old abstractions, that maybe use externals or other abstractions, but don't have any [import] or [declare] inside? I have literally thousands of these on my disk (not all written by me, of course).
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo!
No, I mean the other way around: What about old abstractions, that maybe use externals or other abstractions, but don't have any [import] or [declare] inside? I have literally thousands of these on my disk (not all written by me, of course).
Okay, I undestand, me too ... you could only add the imports when you use them again, or use the preference file (but then it will only work on your computer).
LG Georg
On May 4, 2007, at 10:57 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The idea is to strip down Pd to the most basic objects, then make everything else a library that's included when needed. [import] and/ or [declare] seem to be some of the essential few.
I wonder: How should we deal with the thousands of abstractions that have been created in the ten years since Pd was invented? To avoid having to rewrite every patch, some kind of central path preference mechanism still will be necessary, I guess.
I don't think anyone is proposing to remove the startup flags/
preferences like "path". For the situation that you describe, it
would be easy enough to collect those abstractions into a folder,
then add that folder to the path when you need it. [declare] and
[classpath] allow you to do that in the patch itself.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I don't think anyone is proposing to remove the startup flags/ preferences like "path". For the situation that you describe, it
would be easy enough to collect those abstractions into a folder,
then add that folder to the path when you need it. [declare] and
[classpath] allow you to do that in the patch itself.
Ah, okay. Quick question: What's [classpath]?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On May 4, 2007, at 11:47 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I don't think anyone is proposing to remove the startup flags/ preferences like "path". For the situation that you describe, it would be easy enough to collect those abstractions into a folder, then add that folder to the path when you need it. [declare] and [classpath] allow you to do that in the patch itself.
Ah, okay. Quick question: What's [classpath]?
It's basically like this:
[import] == [declare -lib] Loads a lib for the patch-local namespace
[classpath] == [declare -stdpath] Adds a path to the global search path.
-Hans
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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
On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote:
[classpath] == [declare -stdpath] Adds a path to the global search path.
thats great! - I wasn't aware of [classpath] -- now I can stop
wrangling preferences/users trying to get different paths and
libraries for different versions.
a few questions not explained in the helpfiles:
- is there a way to use relative pathnames?
- and if so what are they relative to?
- is it possible to refer to the users home folder?
- what version of pd do they require
(they seem to create ok in millers OSX 0.40 and 0.39)
- when can I use the libdir system to load a directory of externals?
I hope there are plans for inclusion in the miller pd distribution
soon (though a least it is fairly easy to explain how to add them,
even to a novice user).
thanks for getting this working,
simon
simon wise wrote:
On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote:
[classpath] == [declare -stdpath] Adds a path to the global search path.
thats great! - I wasn't aware of [classpath] -- now I can stop
wrangling preferences/users trying to get different paths and
libraries for different versions.
I hope there are plans for inclusion in the miller pd distribution
soon (though a least it is fairly easy to explain how to add them,
even to a novice user).
hmm, i don't fully understand your request: hans just told you that [classpath] (an external) is basically the same as [decalre -stdpath] (which comes with pd-vanilla)
so why don't you just use [declare]? apart from the fact, that [declare] has a slightly more complicated syntax and merges more or less independent functionality, it also has some advantages: e.g. it is treated specially by pd (it always gets saved as the very first part of the patch, no matter when you actually put the object there; i don't think (but otoh i don't know) that [classpath] can offer you the same)
mfg.a sdr IOhannes
On 7 May 2007, at 5:08 PM, IOhannes m zmoelnig wrote:
so why don't you just use [declare]? apart from the fact, that [declare] has a slightly more complicated syntax and merges more or less independent functionality, it also has some advantages: e.g. it is treated specially by pd (it always gets saved as the very first part of the patch, no matter when you actually put the object there
thanks - how to ensure it was 'first' was the next thing I was trying
to find out,
I'll certainly use [declare], I wasn't aware of what it did - its
relative path choices are exactly what I need. It is new to 0.40?
simon
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
simon wise wrote:
On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote:
[classpath] == [declare -stdpath] Adds a path to the global search path.
thats great! - I wasn't aware of [classpath] -- now I can stop
wrangling preferences/users trying to get different paths and
libraries for different versions.I hope there are plans for inclusion in the miller pd distribution
soon (though a least it is fairly easy to explain how to add them,
even to a novice user).hmm, i don't fully understand your request: hans just told you that [classpath] (an external) is basically the same as [decalre -stdpath] (which comes with pd-vanilla)
Actually I now found that [classpath] according to the help-file in CVS/externals/hcs/classpath-help.pd does something different than [declare -stdpath]: It's not used to *set* the path, but to *get* the searchpath with an interface similar to [textfile]: Each bang sent to [classpath] will make it print the next entry in the current Pd path.
So it's actually not intended for making adjustments to the path, that's left to [declare].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On May 7, 2007, at 4:58 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
simon wise wrote:
On 5 May 2007, at 5:14 AM, Hans-Christoph Steiner wrote:
[classpath] == [declare -stdpath] Adds a path to the global search path.
thats great! - I wasn't aware of [classpath] -- now I can stop wrangling preferences/users trying to get different paths and libraries for different versions.
I hope there are plans for inclusion in the miller pd distribution soon (though a least it is fairly easy to explain how to add them, even to a novice user).
hmm, i don't fully understand your request: hans just told you that [classpath] (an external) is basically the
same as [decalre -stdpath] (which comes with pd-vanilla)Actually I now found that [classpath] according to the help-file in CVS/externals/hcs/classpath-help.pd does something different than [declare -stdpath]: It's not used to *set* the path, but to *get* the searchpath with an interface similar to [textfile]: Each bang sent to [classpath] will make it print the next entry in the current Pd path.
So it's actually not intended for making adjustments to the path, that's left to [declare].
Actually, it is intended both to set the global search path (aka
classpath, aka [declare -stdpath]), but it also allows you to query
the global search path. [import] will allow querying.
That's the intention at least. I haven't looked at it in a bit, so
they do not fully live up to those claims yet. I think I was waiting
for somethings from Miller to settle before taking it up again.
About putting the [declare] object first, I haven't figured that part
out yet. Plus the [declare] ordering was limited/buggy last I
checked (a few months ago?)
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
I solve this problem (on OS X) by keeping my personal paths in .pdrc.
~Kyle
On 5/2/07, marius schebella marius.schebella@gmail.com wrote:
ok found the problem. I did not exchange the preferences file. so all the paths were still set to test7. but acually that is a problem, because I add a lot of my own paths and I don't want to add them everytime when I change the pd version. is it possible to use additional preferences files? hmm, I think I will add them all at the "startup flags" line. So, the paths are working now and I don't need libdir for it to work (libdir itself still doesnot load). marius.
Georg Holzmann wrote:
Hallo!
libdir: can't load library. uidohotswos.
jodesiswor ;)
However, can you try pd -verbose and see what happens ?
LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 3 May 2007, at 5:44 AM, Kyle Klipowicz wrote:
I solve this problem (on OS X) by keeping my personal paths in .pdrc.
which works well for me too.
I'd also love to see a .pdrc, (or a for example a 'local.plist')
which was specific to the version of pd that I was opening, since I
usually have at least 3 - an extended version, a vanilla version plus
usually at least 1 version with a different Gem inside. It would be
great for packages streamlined for different tasks as well.
This could happen in a few ways, for example:
1/ check for a file inside the package
eg Pd.app/Contents/Resources/local.plist
2/ check for a .plist in the usual place, but with a name matching
the name of the Pd.app package
eg if I have a package Pd-extended-autobuild.app then it would use ~/
Library/Preferences/org.puredata.Pd-extended-autobuild.plist instead
of (or as well as??) ~/Library/Preferences/org.puredata.pd.plist
option 1 would be much cleaner in OSX
option 2 would allow for a very similar approach on each platform so
may be better overall. It would also be consistent with the approach
taken by vim, and several others, where behaviour depends on the name
it is called with.
simon
On 3 May 2007, at 2:19 PM, simon wise wrote:
I'd also love to see a .pdrc, (or a for example a 'local.plist')
there is an interesting choice here too
1/ use a local preference file if it exists (instead of the users
one), and the preference dialogue panel modifies that rather than the
users general one
2/ use a .pdrc which is read before the normal preference file, so
the users preference file could override settings done in the .pdrc
(since the .pdrc wouldn't be read by the preference dialogue it
wouldn't be changed if the preferences changed).
This could be quite useful in the Extended version to put in all the
included libraries (and prevent a lot of angst and questions to this
list!) especially if a 'use local pdrc' button was added to the
preference dialogue to turn this feature off if it wasn't wanted or
needed by the user.
3/ a more complete solution, but much more work, would be to allow
both local and user-wide preference files to work together, with some
way of choosing when opening the preference dialogue, or when saving
settings, if changes should be local or global.
I prefer option 2
simon
-
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Kyle Klipowicz -
marius schebella -
simon wise -
Steffen