[PD] new object: [path] - following the example of [import]
reduzent at gmail.com
Thu Dec 1 14:07:50 CET 2011
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
#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  for more details.
More information about the Pd-list