hi
i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones.
e.g. i have a file:
/home/roman/netpd/abs/netpd-r
i made a [declare -path /home/roman/netpd/abs], then i tried to instantiate a [netpd-r], but pd -verbose prints the following pathes:
tried /home/roman/netpd/patches/netpd-r.l_i386 and failed tried /usr/local/lib/pd/extra/netpd-r.l_i386 and failed tried /home/roman/netpd/patches/netpd-r.pd_linux and failed tried /usr/local/lib/pd/extra/netpd-r.pd_linux and failed tried /home/roman/netpd/patches/netpd-r/netpd-r.l_i386 and failed tried /usr/local/lib/pd/extra/netpd-r/netpd-r.l_i386 and failed tried /home/roman/netpd/patches/netpd-r/netpd-r.pd_linux and failed tried /usr/local/lib/pd/extra/netpd-r/netpd-r.pd_linux and failed tried /home/roman/netpd/patches/netpd-r.pd and failed tried /usr/local/lib/pd/extra/netpd-r.pd and failed tried /home/roman/netpd/patches/netpd-r.pat and failed tried /usr/local/lib/pd/extra/netpd-r.pat and failed netpd-r ... couldn't create
/home/roman/netpd/abs doesn't show up in the pathes. why? am i doing something wrong?
i am on miller's pd 0.40.2
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Mon, 2007-05-07 at 16:58 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hi
i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones.
oh yes, i forgot: that's a problem with [declare]; it only gets executed when the patch is loaded....
ah, ok. thanks. however, it works only for the patch, that is containing the [declare]-object, whereas at the same time a [declare -lib /path/to/somelib] makes the objects from the external somelib available for all patches running in the same instance of pd. isn't that kind of inconsistent? i hoped, i could use [declare] to get rid of the pd-startup file for netpd, when netpd is definitely switching to 0.40. but as it works now, every user made patch would need to have a [declare -path ../abs]. this is bad news....... it seems, that netpd will always need a startup-file :-(
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Mon, 2007-05-07 at 16:58 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hi
i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones.
oh yes, i forgot: that's a problem with [declare]; it only gets executed when the patch is loaded....
ah, ok. thanks. however, it works only for the patch, that is containing the [declare]-object, whereas at the same time a [declare -lib /path/to/somelib] makes the objects from the external somelib available for all patches running in the same instance of pd. isn't that kind of inconsistent?
This clearly is a bug in [declare]. I now filed a bug report regarding this behaviour with ID 1714473. Attached is the example I used to illustrate the bug.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-05-07 at 19:55 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Mon, 2007-05-07 at 16:58 +0200, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hi
i cannot get [declare]'s -path-flag working. i tried relative pathes as well as absolute ones.
oh yes, i forgot: that's a problem with [declare]; it only gets executed when the patch is loaded....
ah, ok. thanks. however, it works only for the patch, that is containing the [declare]-object, whereas at the same time a [declare -lib /path/to/somelib] makes the objects from the external somelib available for all patches running in the same instance of pd. isn't that kind of inconsistent?
This clearly is a bug in [declare]. I now filed a bug report regarding this behaviour with ID 1714473. Attached is the example I used to illustrate the bug.
sorry, i didn't check your declare-test-setup. otherwise, i'd have noticed, that we are not speaking about the same thing. what you found, is a far more complex issue than what i was speaking about.
what i meant to be inconsistent:
- [declare -lib somelib] makes the objects of the external 'somelib'
availabe to ALL patches, not only to the [declare]'s parent patch.
- [declare -path somefolder] makes the abstractions from 'somefolder'
available ONLY to the parent patch, i.e. the patch, that contains the [declare].
i don't see why abstractions from a certain location should be handled differently than objects from a certain library? shouldn't they be treated the same (at least from the user's point of view)?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo,
first: Maybe we should avoid the term "parent patch" for the patch, that contains the [declare] object. Generally "parent" seems to be used for specifying the parent of an abstraction as in "graph on parent". One could consider an object like [declare] to be like an abstraction and then its parent would be the patch that contains [declare]. However IMO this becomes confusing when talking about the parent of an abstraction that itself contains the [declare].
Does someone have a better term for the patch, that contains an object? Maybe the "owner" or so.
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
what i meant to be inconsistent:
- [declare -lib somelib] makes the objects of the external 'somelib'
availabe to ALL patches, not only to the [declare]'s parent patch.
Currently it's impossible to "unload" a binary object (builtin or external) from Pd once it is loaded. Loading the wrong [counter] binary will make all your [counter] objects behave like the one loaded first. That's also why you cannot overwrite binary objects with abstractions. Just try it.
So the fact that [declare -lib somelib] acts globally actually is unavoidable and might even be considered a bug.
- [declare -path somefolder] makes the abstractions from 'somefolder'
available ONLY to the parent patch, i.e. the patch, that contains the [declare].
That's the idea IIRC: Only the "owner" should see that modified path. Unfortunatly that behaviuor is currently broken for [declare -path ...] in abstractions.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-05-28 at 22:42 +0200, Frank Barknecht wrote:
Hallo,
first: Maybe we should avoid the term "parent patch" for the patch, that contains the [declare] object. Generally "parent" seems to be used for specifying the parent of an abstraction as in "graph on parent". One could consider an object like [declare] to be like an abstraction and then its parent would be the patch that contains [declare]. However IMO this becomes confusing when talking about the parent of an abstraction that itself contains the [declare].
Does someone have a better term for the patch, that contains an object? Maybe the "owner" or so.
yeah, using 'parent' lead to confusions. i'll use 'owner patch' in the future.
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
what i meant to be inconsistent:
- [declare -lib somelib] makes the objects of the external 'somelib'
availabe to ALL patches, not only to the [declare]'s parent patch.
Currently it's impossible to "unload" a binary object (builtin or external) from Pd once it is loaded. Loading the wrong [counter] binary will make all your [counter] objects behave like the one loaded first. That's also why you cannot overwrite binary objects with abstractions. Just try it.
So the fact that [declare -lib somelib] acts globally actually is unavoidable and might even be considered a bug.
- [declare -path somefolder] makes the abstractions from 'somefolder'
available ONLY to the parent patch, i.e. the patch, that contains the [declare].
That's the idea IIRC: Only the "owner" should see that modified path. Unfortunatly that behaviuor is currently broken for [declare -path ...] in abstractions.
thanks for the explanations. that makes sense for me now. am i right then, that:
[declare myfolder] [myabs]
and
[myfolder/myabs]
are essentially the same thing? if yes, what is the advantage of using [declare]?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On May 28, 2007, at 6:03 PM, Roman Haefeli wrote:
On Mon, 2007-05-28 at 22:42 +0200, Frank Barknecht wrote:
Hallo,
first: Maybe we should avoid the term "parent patch" for the patch, that contains the [declare] object. Generally "parent" seems to be used for specifying the parent of an abstraction as in "graph on parent". One could consider an object like [declare] to be like an abstraction and then its parent would be the patch that contains [declare]. However IMO this becomes confusing when talking about the parent of an abstraction that itself contains the [declare].
Does someone have a better term for the patch, that contains an object? Maybe the "owner" or so.
yeah, using 'parent' lead to confusions. i'll use 'owner patch' in the future.
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
what i meant to be inconsistent:
- [declare -lib somelib] makes the objects of the external 'somelib'
availabe to ALL patches, not only to the [declare]'s parent patch.
Currently it's impossible to "unload" a binary object (builtin or external) from Pd once it is loaded. Loading the wrong [counter] binary will make all your [counter] objects behave like the one
loaded first. That's also why you cannot overwrite binary objects with abstractions. Just try it.So the fact that [declare -lib somelib] acts globally actually is unavoidable and might even be considered a bug.
- [declare -path somefolder] makes the abstractions from
'somefolder' available ONLY to the parent patch, i.e. the patch, that contains
the [declare].That's the idea IIRC: Only the "owner" should see that modified path. Unfortunatly that behaviuor is currently broken for [declare -path ...] in abstractions.
thanks for the explanations. that makes sense for me now. am i right then, that:
[declare myfolder] [myabs]
and
[myfolder/myabs]
are essentially the same thing? if yes, what is the advantage of using [declare]?
Yeah, they are essentially the same thing. The advantages of using
[declare] would be that the names are shorter and perhaps more
readable in the context of that patch. Plus the help files would
work :-/. IIRC, cliking "Help" on [myfolder/myabs] won't find the
help file. That should be fixed, but it's not simple, unfortunately.
.hc
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, they are essentially the same thing. The advantages of using
[declare] would be that the names are shorter and perhaps more
readable in the context of that patch. Plus the help files would
work :-/. IIRC, cliking "Help" on [myfolder/myabs] won't find the
help file.
If the help file was next to myabs in in myfolder/myabs-help.pd it would be found as usual for both cases.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On May 29, 2007, at 3:34 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, they are essentially the same thing. The advantages of using [declare] would be that the names are shorter and perhaps more readable in the context of that patch. Plus the help files would work :-/. IIRC, cliking "Help" on [myfolder/myabs] won't find the help file.
If the help file was next to myabs in in myfolder/myabs-help.pd it would be found as usual for both cases.
Ah right, I think it works (or doesn't work) the way I describe when
using binary Pd objects.
.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
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
Frank Barknecht wrote:
Hallo,
- [declare -lib somelib] makes the objects of the external 'somelib'
availabe to ALL patches, not only to the [declare]'s parent patch.
Currently it's impossible to "unload" a binary object (builtin or external) from Pd once it is loaded. Loading the wrong [counter] binary will make all your [counter] objects behave like the one loaded first. That's also why you cannot overwrite binary objects with abstractions. Just try it.
in fact it IS possible, as krzysztof has shown in cyclone. (ok, it is not real "unloading" (as in: freeing memory) but you can manipulate pd's object-table, once you have manged to run a certain function in your library.
but imo its dirty
fg.sER IOhannes
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Roman Haefeli