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=detailaid=1403917group_id=55736atid=478072 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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@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=detailaid=1403917group_id=55736atid=478072 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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 ? __ | 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
Re: [PD] save search path 0.43 OSX
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Roman Haefeli reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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]? fgmasdr IOhannes [1] https://sourceforge.net/tracker/?func=detailaid=1403917group_id=55736atid=478072 -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- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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=detailaid=1403917group_id=55736atid=478072 Yeah, that makes sense. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
- Original Message - From: IOhannes m zmoelnig zmoel...@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=detailaid=1403917group_id=55736atid=478072 -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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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. __ | 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
Re: [PD] save search path 0.43 OSX
Le 2012-02-27 à 12:58:00, Jonathan Wilkes a écrit : From: Mathieu Bouchard ma...@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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Jonathan Wilkes jancs...@yahoo.com Cc: IOhannes m zmoelnig zmoel...@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 ma...@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_canvas-help.pd?view=log __ | 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
Re: [PD] save search path 0.43 OSX
On Fri, 2012-02-24 at 12:14 -0800, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: m.e.grimm megr...@gmail.com Cc: Jonathan Wilkes jancs...@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]. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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 reduz...@gmail.com To: m.e.grimm megr...@gmail.com Cc: Jonathan Wilkes jancs...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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 reduz...@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 muran...@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 h...@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 h...@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.andr...@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
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.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
- Original Message - From: Roman Haefeli reduz...@gmail.com To: m.e.grimm megr...@gmail.com Cc: Jonathan Wilkes jancs...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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 h...@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 h...@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.andr...@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
Re: [PD] save search path 0.43 OSX
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 muran...@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 h...@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 h...@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.andr...@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
Re: [PD] save search path 0.43 OSX
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 muran...@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 h...@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 h...@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.andr...@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
Re: [PD] save search path 0.43 OSX
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 muran...@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 h...@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 h...@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.andr...@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] save search path 0.43 OSX
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
Re: [PD] save search path 0.43 OSX
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.andr...@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
Re: [PD] save search path 0.43 OSX
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.andr...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
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 h...@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.andr...@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
Re: [PD] save search path 0.43 OSX
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 h...@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.andr...@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
