Hi IOhannes
On Thu, 2011-12-01 at 11:45 +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hmm, my usual 2 remarks:
On 2011-12-01 06:21, Hans-Christoph Steiner wrote:
#2 how does this object relate to the quest to eliminate path settings alltogether? i thought "-path" is really only for nerds like me who feel unable to use standard paths :-)
Currently to only way to enable paths relative to patch is using [declare], which does not take immediate effect. As I understand, [path] is supposed to replace [declare -path], so it provides an alternative (immediate) way to load (non-standard) paths. So it helps at least as much as [declare] to eliminate any global path settings and let the patch handle the paths by itself.
#3 could anybody tell me why [declare] does not take immediate effect?
I'll try to explain the way of how (I think) [declare] works.
When you create a [declare] object somewhere in your patch, it just does nothing at all at this moment. Only when you save your patch, Pd will parse the patch and thus look for any [declare] objects and insert right after the first line of the file one additional line per declare object like this:
#X declare -stdpath extra/osc;
Please note, there is still the original:
#X obj 12 72 declare -stdpath extra/osc;
line somewhere in the patch, which refers to the actual [declare] object.
When loading the patch the next time, Pd will find the '#X declare' line and enable libraries and paths accordingly _before_ the rest of the patch is loaded. This is why [declare] does not take immediate effect.
Roman
P.S.: This (IMHO, a bit kludgey) way of how [declare] works is also the reason, why abstractions containing [declare] objects pollute the most parent patch, when the latter is saved, which is IMHO a relatively serious bug. Please refer to [1] for more details. [1] http://sourceforge.net/tracker/?func=detail&aid=2251387&group_id=557...