Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android < joson.android@googlemail.com> wrote:
Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android joson.android@googlemail.com wrote: Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny _______________________________________________ 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
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.at wrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the
interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android < joson.android@googlemail.com> wrote:
Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yup, I agree, it should be represented clearly somehow I'm open to suggestions. Its been a long time policy in Pd-extended to avoid using the preferences. Its only recently been enforced.
.hc
On Feb 18, 2012, at 3:26 PM, András Murányi wrote:
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.at wrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android joson.android@googlemail.com wrote: Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny _______________________________________________ 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
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Huh, afaik there has been no such warning for deprecation ever planted in Pd so there is nothing to conform with. If it gets implemented, it will be something helpful and ugly - for a temporary period of time. Three ways come into my mind:
- an "alert box" (modal dialog with the warning and an OK button) that
appears when you click the menu item, and of course when you click OK the actual path dialog appears,
- a sort of "textual link" somewhere on the path dialog box itself, could
look like "Editing paths here is deprecated. *See why, and how to edit paths *", and it would lead to a certain help page,
- putting back the Save button, with no other functionality than displaying
the aforementioned alert box.
András
2012/2/19 Hans-Christoph Steiner hans@at.or.at
Yup, I agree, it should be represented clearly somehow I'm open to suggestions. Its been a long time policy in Pd-extended to avoid using the preferences. Its only recently been enforced.
.hc
On Feb 18, 2012, at 3:26 PM, András Murányi wrote:
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.atwrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the
interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android < joson.android@googlemail.com> wrote:
Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny _______________________________________________ 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
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
A lot of external developers obviously got used to relying on
the libs that were loaded by default in previous versions of Pd extended. If their help patches rely on
some of those externals and the dev didn't give a lib prefix, those objects won't load under the new system.
Hans-- is there a way to automate fixing these, or did you already address this issue?
-Jonathan
From: András Murányi muranyia@gmail.com To: pd-list pd-list@iem.at Sent: Thursday, February 23, 2012 2:01 PM Subject: Re: [PD] save search path 0.43 OSX
Huh, afaik there has been no such warning for deprecation ever planted in Pd so there is nothing to conform with. If it gets implemented, it will be something helpful and ugly - for a temporary period of time. Three ways come into my mind:
- an "alert box" (modal dialog with the warning and an OK button) that appears when you click the menu item, and of course when you click OK the actual path dialog appears,
- a sort of "textual link" somewhere on the path dialog box itself, could look like "Editing paths here is deprecated. See why, and how to edit paths", and it would lead to a certain help page,
- putting back the Save button, with no other functionality than displaying the aforementioned alert box.
András
2012/2/19 Hans-Christoph Steiner hans@at.or.at
Yup, I agree, it should be represented clearly somehow I'm open to suggestions. Its been a long time policy in Pd-extended to avoid using the preferences. Its only recently been enforced.
.hc
On Feb 18, 2012, at 3:26 PM, András Murányi wrote:
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.at wrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android joson.android@googlemail.com wrote:
Dear List!
i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? Also, when i make changes in 0.42.5, 0.43 will know about them on next startup.
I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended.
Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help...
Johnny _______________________________________________ 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
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I've been fixing them as I find them. Plus I've been running the load-every-help script and checking the log. That will show you any object that failed to create.
.hc
On Thu, Feb 23, 2012, at 13:41, Jonathan Wilkes wrote:
A lot of external developers obviously got used to relying on
the libs that were loaded by default in previous versions of Pd extended. If their help patches rely on
some of those externals and the dev didn't give a lib prefix, those objects won't load under the new system.
Hans-- is there a way to automate fixing these, or did you already address this issue?
-Jonathan
From: András Murányi muranyia@gmail.com To: pd-list pd-list@iem.at Sent: Thursday, February 23, 2012 2:01 PM Subject: Re: [PD] save search path 0.43 OSX
Huh, afaik there has been no such warning for deprecation ever planted in Pd so there is nothing to conform with. If it gets implemented, it will be something helpful and ugly - for a temporary period of time. Three ways come into my mind:
- an "alert box" (modal dialog with the warning and an OK button) that appears when you click the menu item, and of course when you click OK the actual path dialog appears,
- a sort of "textual link" somewhere on the path dialog box itself, could look like "Editing paths here is deprecated. See why, and how to edit paths", and it would lead to a certain help page,
- putting back the Save button, with no other functionality than displaying the aforementioned alert box.
András
2012/2/19 Hans-Christoph Steiner hans@at.or.at
Yup, I agree, it should be represented clearly somehow I'm open to suggestions. Its been a long time policy in Pd-extended to avoid using the preferences. Its only recently been enforced.
.hc
On Feb 18, 2012, at 3:26 PM, András Murányi wrote:
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.at wrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android joson.android@googlemail.com wrote:
Dear List! > >i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? >Also, when i make changes in 0.42.5, 0.43 will know about them on next startup. > >I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended. > >Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help... > >Johnny >_______________________________________________ >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
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
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
On Thu, 2012-02-23 at 13:41 -0800, Jonathan Wilkes wrote:
A lot of external developers obviously got used to relying on
the libs that were loaded by default in previous versions of Pd extended. If their help patches rely on
some of those externals and the dev didn't give a lib prefix, those objects won't load under the new system.
I think the better way to fix those help-files is to use an [import] or [declare] object in the help patch. This way those help patches may also work outside the Pd-extended context (for instance, if you use multi-class externals).
Roman
From: András Murányi muranyia@gmail.com To: pd-list pd-list@iem.at Sent: Thursday, February 23, 2012 2:01 PM Subject: Re: [PD] save search path 0.43 OSX
Huh, afaik there has been no such warning for deprecation ever planted in Pd so there is nothing to conform with. If it gets implemented, it will be something helpful and ugly - for a temporary period of time. Three ways come into my mind:
- an "alert box" (modal dialog with the warning and an OK button) that appears when you click the menu item, and of course when you click OK the actual path dialog appears,
- a sort of "textual link" somewhere on the path dialog box itself, could look like "Editing paths here is deprecated. See why, and how to edit paths", and it would lead to a certain help page,
- putting back the Save button, with no other functionality than displaying the aforementioned alert box.
András
2012/2/19 Hans-Christoph Steiner hans@at.or.at
Yup, I agree, it should be represented clearly somehow I'm open to suggestions. Its been a long time policy in Pd-extended to avoid using the preferences. Its only recently been enforced.
.hc
On Feb 18, 2012, at 3:26 PM, András Murányi wrote:
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.at wrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer.
for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well.
scott
On Sat, Feb 18, 2012 at 10:17 AM, Joson Android joson.android@googlemail.com wrote:
Dear List! > >i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? >Also, when i make changes in 0.42.5, 0.43 will know about them on next startup. > >I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended. > >Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help... > >Johnny >_______________________________________________ >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
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
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
I think the better way to fix those help-files is to use an [import] or [declare] object in the help patch.
one prob I have found ... in a lib such as "rtc" the objects are not compiled externals but abstractions that rely on "list-abs". how to deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done.
m
On Fri, Feb 24, 2012 at 2:25 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2012-02-23 at 13:41 -0800, Jonathan Wilkes wrote:
A lot of external developers obviously got used to relying on
the libs that were loaded by default in previous versions of Pd extended. If their help patches rely on
some of those externals and the dev didn't give a lib prefix, those objects won't load under the new system.
I think the better way to fix those help-files is to use an [import] or [declare] object in the help patch. This way those help patches may also work outside the Pd-extended context (for instance, if you use multi-class externals).
Roman
From: András Murányi muranyia@gmail.com To: pd-list pd-list@iem.at Sent: Thursday, February 23, 2012 2:01 PM Subject: Re: [PD] save search path 0.43 OSX
Huh, afaik there has been no such warning for deprecation ever planted in Pd so there is nothing to conform with. If it gets implemented, it will be something helpful and ugly - for a temporary period of time. Three ways come into my mind:
- an "alert box" (modal dialog with the warning and an OK button) that appears when you click the menu item, and of course when you click OK the actual path dialog appears,
- a sort of "textual link" somewhere on the path dialog box itself, could look like "Editing paths here is deprecated. See why, and how to edit paths", and it would lead to a certain help page,
- putting back the Save button, with no other functionality than displaying the aforementioned alert box.
András
2012/2/19 Hans-Christoph Steiner hans@at.or.at
Yup, I agree, it should be represented clearly somehow I'm open to suggestions. Its been a long time policy in Pd-extended to avoid using the preferences. Its only recently been enforced.
.hc
On Feb 18, 2012, at 3:26 PM, András Murányi wrote:
Ugh, I more and more tend to think that this info shall be directly accessible from the affected dialog window. Many people may think their Pd is just broken and they might just have no idea what to do about it.
Andras
On Sat, Feb 18, 2012 at 20:59, Hans-Christoph Steiner hans@at.or.at wrote:
Setting the paths and the libraries to load at start time via the preferences is deprecated in Pd-extended 0.43. The way to do this is:
- for the global path, add your libraries, etc. to the built-in user path:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
- for a path local to a patch, use the new [path] object, following the interface of [import] with the functionality of [declare -path]
If you really want to still set the paths via the preferences, you can edit the preferences file, and Pd-extended will still load them from the preferences file.
So in your case, Scott, it sounds like you are using a preferences file that has your extra paths in it already. The Preferences interface in Pd-extended 0.43 no longer saves the paths to the file, so it doesn't override your previously saved extra paths. Try renaming or deleting your preferences file.
.hc
On Feb 18, 2012, at 2:05 PM, Scott R. Looney wrote:
well, just to add my experience i think i can set search paths correctly, but i would like to add that it seems to be quite difficult to have more than one instance of PD-extended 0.43 on the computer (trying mac OS 10.6.4 w/ 32bit and 64bit builds) making it a bit challenging to check one build's operation/stability against another on the same computer. > > >for example, the help browser shows all instances of installed objects on the computer, and then console complains about multiple versions of files existing. i've tried deleting the extra paths that show up to limit things, which works temporarily, but on the next startup it just reverts back to grabbing everything it can find again. it works the same in every .43 pd-extended build i've tried so far (several version of both 32 and 64 bit builds in Dec/Jan). putting things on other drives doesn't work either - it will find those paths as well. > > >scott > > >On Sat, Feb 18, 2012 at 10:17 AM, Joson Android joson.android@googlemail.com wrote: > >Dear List! >> >>i love pd-extended-0.43 !! but i cannot add any search path in the prefferences. It will show my new settings right when i make changes but wont save anything. It prints "ripts/../extra/mapping: no such object" in the pd-window. It works in pd-extended-0.42.5 . Should there be a file where pd saves the path? Where is it? >>Also, when i make changes in 0.42.5, 0.43 will know about them on next startup. >> >>I use OSX10.6.7 and the latest autobuild of xi386 version of 0.43.1-extended. >> >>Maybe it is the fault of chaotic me and chaotic computer, so i deleted all old versions of pd, but that didn't help... >> >>Johnny >>_______________________________________________ >>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
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2012-02-24 at 11:37 -0500, m.e.grimm wrote:
I think the better way to fix those help-files is to use an [import] or [declare] object in the help patch.
one prob I have found ... in a lib such as "rtc" the objects are not compiled externals but abstractions that rely on "list-abs". how to deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done.
Interesting that you say that. I always thought it is the very goal of using [import]: make any patch or abstraction resolve its own dependencies.
In what way [import] shouldn't be used inside abstractions?
(I specifically mention only [import] now, since [declare] has its own implications, though if it would be free of bugs, I'd mentioned it as well.)
Roman
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: m.e.grimm megrimm@gmail.com Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list pd-list@iem.at Sent: Friday, February 24, 2012 2:57 PM Subject: Re: [PD] save search path 0.43 OSX
On Fri, 2012-02-24 at 11:37 -0500, m.e.grimm wrote:
I think the better way to fix those help-files is to use an [import]
or
[declare] object in the help patch.
one prob I have found ... in a lib such as "rtc" the objects are
not
compiled externals but abstractions that rely on "list-abs". how
to
deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done.
Interesting that you say that. I always thought it is the very goal of using [import]: make any patch or abstraction resolve its own dependencies.
In what way [import] shouldn't be used inside abstractions?
(I specifically mention only [import] now, since [declare] has its own implications, though if it would be free of bugs, I'd mentioned it as well.)
So we have [import] which isn't in vanilla, [declare] which you say has bugs, and using "libname/" prefixes which works for both vanilla and extended. What am I missing?
-Jonathan
Roman
On Fri, 2012-02-24 at 12:14 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: m.e.grimm megrimm@gmail.com Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list pd-list@iem.at Sent: Friday, February 24, 2012 2:57 PM Subject: Re: [PD] save search path 0.43 OSX
On Fri, 2012-02-24 at 11:37 -0500, m.e.grimm wrote:
I think the better way to fix those help-files is to use an [import]
or
[declare] object in the help patch.
one prob I have found ... in a lib such as "rtc" the objects are
not
compiled externals but abstractions that rely on "list-abs". how
to
deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done.
Interesting that you say that. I always thought it is the very goal of using [import]: make any patch or abstraction resolve its own dependencies.
In what way [import] shouldn't be used inside abstractions?
(I specifically mention only [import] now, since [declare] has its own implications, though if it would be free of bugs, I'd mentioned it as well.)
So we have [import] which isn't in vanilla, [declare] which you say has bugs, and using "libname/" prefixes which works for both vanilla and extended. What am I missing?
Many libraries come as multi-class externals, either because you compiled them yourself and this is the default setup designed by the developer or you get them as package (in Debian, for instance). For all those libraries, [libname/classname] will simply break. OTOH, [declare] already works now (in both, Pd-vanilla and Pd-extended) [1], or you could use [import] which you can easily install (for instance, in Debian there is already a package).
I think, it's much easier to find a way to load a certain library (either with start-up flags, [declare] or [import]) than to have to edit a patch and make it work by replacing all occurences of [libname/classname] by [classname].
Roman
[1] The one known bug in [declare] I was thinking about doesn't affect its functionality, it works fine, but when used within abstractions, it will add a bogus line in the parents patch file, when the parent is saved. People need to be aware of that when using [declare].
On Sun, 2012-02-26 at 11:49 +0100, Roman Haefeli wrote:
On Fri, 2012-02-24 at 12:14 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: m.e.grimm megrimm@gmail.com Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list pd-list@iem.at Sent: Friday, February 24, 2012 2:57 PM Subject: Re: [PD] save search path 0.43 OSX
On Fri, 2012-02-24 at 11:37 -0500, m.e.grimm wrote:
I think the better way to fix those help-files is to use an [import]
or
[declare] object in the help patch.
one prob I have found ... in a lib such as "rtc" the objects are
not
compiled externals but abstractions that rely on "list-abs". how
to
deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done.
Interesting that you say that. I always thought it is the very goal of using [import]: make any patch or abstraction resolve its own dependencies.
In what way [import] shouldn't be used inside abstractions?
(I specifically mention only [import] now, since [declare] has its own implications, though if it would be free of bugs, I'd mentioned it as well.)
So we have [import] which isn't in vanilla, [declare] which you say has bugs, and using "libname/" prefixes which works for both vanilla and extended. What am I missing?
Many libraries come as multi-class externals, either because you compiled them yourself and this is the default setup designed by the developer or you get them as package (in Debian, for instance). For all those libraries, [libname/classname] will simply break. OTOH, [declare] already works now (in both, Pd-vanilla and Pd-extended) [1], or you could use [import] which you can easily install (for instance, in Debian there is already a package).
I think, it's much easier to find a way to load a certain library (either with start-up flags, [declare] or [import]) than to have to edit a patch and make it work by replacing all occurences of [libname/classname] by [classname].
For completeness, let me add that it doesn't matter with abstraction libraries whether you use [import libname] or [libname/classname]. So in that specific case with the rtc lib and list-abs I agree with you that [libname/classname] is fine.
Roman
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside abstractions?
[import] is not very local, is it ?
As long as the constructor-table is still one big table (the method-list of the objectmaker class), you can't escape the fact that importing any set of names «in» an abstraction or any patch, is going to import in the global namespace instead, and potentially conflict with anything imported by anything else that you wanted to avoid conflict with.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside abstractions?
[import] is not very local, is it ?
But it also works with multi-class externals. See my other mail.
Roman
Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside abstractions?
[import] is not very local, is it ?
But it also works with multi-class externals. See my other mail.
But it's not very local, is it ?
Where does it import symbols to ? A big global namespace.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Feb 26, 2012, at 11:50 AM, Mathieu Bouchard wrote:
Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside abstractions?
[import] is not very local, is it ?
But it also works with multi-class externals. See my other mail.
But it's not very local, is it ?
Where does it import symbols to ? A big global namespace.
Yup, binary objects will be imported into the global namespace. Abstractions will be local though.
.hc
There is no way to peace, peace is the way. -A.J. Muste
Le 2012-02-26 à 14:11:00, Hans-Christoph Steiner a écrit :
On Feb 26, 2012, at 11:50 AM, Mathieu Bouchard wrote:
Where does it import symbols to ? A big global namespace.
Yup, binary objects will be imported into the global namespace. Abstractions will be local though.
Oh, yes, because abstractions are never listed as part of pd_objectmaker : only externals are.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Sun, 2012-02-26 at 11:50 -0500, Mathieu Bouchard wrote:
Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside abstractions?
[import] is not very local, is it ?
But it also works with multi-class externals. See my other mail.
But it's not very local, is it ?
I got it (why are you repeating it?) [zexy/dirac~] just simply doesn't work on a Debian box that has puredata and pd-zexy installed.
Where does it import symbols to ? A big global namespace.
It seems that [zexy/dirac~] adds 'dirac~' to the global namespace, not 'zexy/dirac~'. At least, when I create [zexy/dirac~] in a patch in Pd-extended, I can create instances of [dirac~] afterwards.
Roman
Le 2012-02-27 à 16:44:00, Roman Haefeli a écrit :
On Sun, 2012-02-26 at 11:50 -0500, Mathieu Bouchard wrote:
Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside abstractions?
[import] is not very local, is it ?
But it also works with multi-class externals. See my other mail.
But it's not very local, is it ?
I got it (why are you repeating it?)
Because my point is that it doesn't import names of externals locally. So if it's not local, then it doesn't really matter that it does the same (?) with multi-class externals, because that's not what it should do.
Fortunately, nameclashes are a relatively rare occurrence, otherwise we'd more often hear things like « restart pd in order to avoid nameclashes caused by [import] being present in patches that have already been closed ».
[zexy/dirac~] just simply doesn't work on a Debian box that has puredata and pd-zexy installed. It seems that [zexy/dirac~] adds 'dirac~' to the global namespace, not 'zexy/dirac~'. At least, when I create [zexy/dirac~] in a patch in Pd-extended, I can create instances of [dirac~] afterwards.
So, is this a bug in Zexy, or a bug in the way «namespacing» is implemented ? What does this case prove ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Roman Haefeli reduzent@gmail.com Cc: pd-list pd-list@iem.at Sent: Monday, February 27, 2012 11:40 AM Subject: Re: [PD] save search path 0.43 OSX
Le 2012-02-27 à 16:44:00, Roman Haefeli a écrit :
On Sun, 2012-02-26 at 11:50 -0500, Mathieu Bouchard wrote:
Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
In what way [import] shouldn't be used inside
abstractions?
[import] is not very local, is it ?
But it also works with multi-class externals. See my other mail.
But it's not very local, is it ?
I got it (why are you repeating it?)
Because my point is that it doesn't import names of externals locally. So if it's not local, then it doesn't really matter that it does the same (?) with multi-class externals, because that's not what it should do.
Fortunately, nameclashes are a relatively rare occurrence, otherwise we'd more often hear things like « restart pd in order to avoid nameclashes caused by [import] being present in patches that have already been closed ».
[zexy/dirac~] just simply doesn't work on a Debian box that has
puredata and pd-zexy installed. It seems that [zexy/dirac~] adds 'dirac~' to the global namespace, not 'zexy/dirac~'. At least, when I create [zexy/dirac~] in a patch in Pd-extended, I can create instances of [dirac~] afterwards.
So, is this a bug in Zexy, or a bug in the way «namespacing» is implemented ? What does this case prove ?
Here is (maybe) a related issue:
- patch a.pd has abstraction [foo/prop_dialog]
- patch b.pd has abstraction [bar/prop_dialog]
I send "vis 1" message to pd-prop_dialog.pd and both foo/prop_dialog and bar/prop_dialog will pop up. How do I vis just foo/prop_dialog?
So just use [sendcanvas] or [namecanvas] or whatever. But let's say I've got an abstraction [foo/sosc~] that scales its output based on its (x,y) vicinity to other instances of itself in the patch. So I broadcast a message to pd-sosc~.pd to get all the x,y positions, but this will send to bar/sosc~, too.
Sorry for the obscure example, but I think it's important for abstractions to have some way of accessing "class-wide" data-- like this:
[receive pd-someabstraction.pd] | [route echo] | [route our_shared_float] | | [42, bang( <-- let's change and tell all our siblings the shared float |/ [v $0-count] | [prepend echo our_shared_float] | [list trim] | [send pd-someabstraction.pd]
All abstraction can now get the shared float to [v $0-count], but we'll be leaking it to any other abstraction in the global namespace that happens to have the name we gave to our abstraction. Registering the abstraction's name as pd-foo/someabstraction.pd would fix this, but I'm not sure what side effects this would cause.
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-27 18:22, Jonathan Wilkes wrote:
Sorry for the obscure example, but I think it's important for abstractions to have some way of accessing "class-wide" data-- like this:
you mean something like [1]?
fgmasdr IOhannes
[1] https://sourceforge.net/tracker/?func=detail&aid=1403917&group_id=55...
On Feb 27, 2012, at 12:31 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-27 18:22, Jonathan Wilkes wrote:
Sorry for the obscure example, but I think it's important for abstractions to have some way of accessing "class-wide" data-- like this:
you mean something like [1]?
fgmasdr IOhannes
[1] https://sourceforge.net/tracker/?func=detail&aid=1403917&group_id=55...
Yeah, that makes sense.
.hc
Access to computers should be unlimited and total. - the hacker ethic
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list pd-list@iem.at Cc: Sent: Monday, February 27, 2012 12:31 PM Subject: Re: [PD] save search path 0.43 OSX
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-27 18:22, Jonathan Wilkes wrote:
Sorry for the obscure example, but I think it's important for
abstractions to have some way
of accessing "class-wide" data-- like this:
you mean something like [1]?
Exactly! I looked at that after I started fooling around with my canvas "get" method, but I forgot about it. It looks like you are addinga receive-symbol so it should be backwards compatible.
Hans-- if there are no side effects to this, could you add this patch to pd extended?
Any idea what Miller's comment means by a "control" inlet for canvases? Miller?
-Jonathan
fgmasdr IOhannes
[1] https://sourceforge.net/tracker/?func=detail&aid=1403917&group_id=55...
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9Lvf4ACgkQkX2Xpv6ydvTi5ACgwxUg5XyMKd5SMjMCk9Mcdqjs w7wAoLtnPILujVv/5bZA+Df/wC3Mq3k7 =laaL -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: IOhannes m zmoelnig zmoelnig@iem.at; pd-list pd-list@iem.at Sent: Monday, February 27, 2012 3:18 PM Subject: Re: [PD] save search path 0.43 OSX
Le 2012-02-27 à 12:11:00, Jonathan Wilkes a écrit :
Any idea what Miller's comment means by a "control" inlet for
canvases?
It means that mysterious remarks made six years ago should be disregarded.
But what if this mysterious "control" inlet could be the key that unlocks the door to Maximus P? How long must we [bang(--[until] we reach the promised land?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-27 à 12:58:00, Jonathan Wilkes a écrit :
From: Mathieu Bouchard matju@artengine.ca It means that mysterious remarks made six years ago should be disregarded.
But what if this mysterious "control" inlet could be the key that unlocks the door to Maximus P? How long must we [bang(--[until] we reach the promised land?
I don't know. I don't want to go to Maximus P.
Isn't Maximus P an optional side quest ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: IOhannes m zmoelnig zmoelnig@iem.at; pd-list pd-list@iem.at Sent: Monday, February 27, 2012 4:09 PM Subject: Re: [PD] save search path 0.43 OSX
Le 2012-02-27 à 12:58:00, Jonathan Wilkes a écrit :
From: Mathieu Bouchard matju@artengine.ca It means that mysterious remarks made six years ago should be
disregarded.
But what if this mysterious "control" inlet could be the key that
unlocks the door to Maximus P? How long must we [bang(--[until] we reach the promised land?
I don't know. I don't want to go to Maximus P.
Isn't Maximus P an optional side quest ?
No, this is a side-quest... http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/my_canv...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-02-27 à 18:31:00, IOhannes m zmoelnig a écrit :
On 2012-02-27 18:22, Jonathan Wilkes wrote:
Sorry for the obscure example, but I think it's important for abstractions to have some way of accessing "class-wide" data-- like this:
you mean something like [1]? [1] https://sourceforge.net/tracker/?func=detail&aid=1403917&group_id=55...
It's related, but the need is for something that doesn't depend on the way it's written : if [import shadok] then [shadok/gibi] and [gibi] might be the same, but will use different receive-symbols.
But more importantly, what you suggest is for accessing all canvas-objects that are of a same abstraction-class, which is not the same as sharing various properties that belong to a certain abstraction-class.
I mean that the canvas-object used to make an abstraction-object is not the same as the abstraction-object itself. The canvas-object does not directly handle stuff that is implemented in pd, and its receive-symbols are really about canvas-responsibilities.
So if an abstraction pretends to be a canvas using [receive] in an attempt to extend the list of methods that the object supports, then every message not meant for the canvas will cause « canvas: no such method ».
An abstraction-object's canvas object, even though it represents the object itself, usually shouldn't be talked to directly from outside, as the abstraction-class is what is supposed to know whether and how 'vis', 'coords', etc., should be used.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pd-list pd-list@iem.at Sent: Saturday, March 3, 2012 3:36 PM Subject: Re: [PD] save search path 0.43 OSX
Le 2012-02-27 à 18:31:00, IOhannes m zmoelnig a écrit :
On 2012-02-27 18:22, Jonathan Wilkes wrote:
Sorry for the obscure example, but I think it's important for
abstractions to have some way
of accessing "class-wide" data-- like this:
you mean something like [1]? [1]
https://sourceforge.net/tracker/?func=detail&aid=1403917&group_id=55...
It's related, but the need is for something that doesn't depend on the way it's written : if [import shadok] then [shadok/gibi] and [gibi] might be the same, but will use different receive-symbols.
But more importantly, what you suggest is for accessing all canvas-objects that are of a same abstraction-class, which is not the same as sharing various properties that belong to a certain abstraction-class.
I think I have a different solution which doesn't need an "echo" method for canvases.
To send globally to _this_ abstraction, just concatenate the directory it lives in with the filename.
To send to all instances on the parent canvas, just send to the above prefixed with the parent $0.
To send to all instances anywhere up to the toplevel, just send to toplevel $0 plus dir plus filename.
However, if you are in the parent patch and you want to send to all the abstractions that are children of the parent patch (non-locally), pd-foo/bar.pd seems like the only way to do that.
I mean that the canvas-object used to make an abstraction-object is not the same as the abstraction-object itself. The canvas-object does not directly handle stuff that is implemented in pd, and its receive-symbols are really about canvas-responsibilities.
So if an abstraction pretends to be a canvas using [receive] in an attempt to extend the list of methods that the object supports, then every message not meant for the canvas will cause « canvas: no such method ».
Right, that's what the "echo" method is about.
An abstraction-object's canvas object, even though it represents the object itself, usually shouldn't be talked to directly from outside, as the abstraction-class is what is supposed to know whether and how 'vis', 'coords', etc., should be used.
My alternative method outlined above avoids this.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
András Murányi -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
Joson Android -
m.e.grimm -
Mathieu Bouchard -
Roman Haefeli -
Scott R. Looney