[PD] new object: [path] - following the example of [import]

Roman Haefeli reduzent at gmail.com
Thu Dec 1 14:07:50 CET 2011

Hi IOhannes

On Thu, 2011-12-01 at 11:45 +0100, IOhannes m zmoelnig wrote:
> 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]

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.


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.

More information about the Pd-list mailing list