[PD] installatation path of help-files

marius schebella marius.schebella at gmail.com
Wed Apr 16 16:19:28 CEST 2008

I think your examples do not cover all usecases.
declare is supposed to solve the nameclash problem: it should also 
provide local patch namespaces. (dealing with the whole problematic of 
nameclashes can appear in several situations: (conflict between 
external/abstraction vs. external/abstraction)
dealing with the current mess of double names on your local system, but 
also dealing with double names on your computer vs. other systems, 
especially when you want to share patches and make sure they work on 
other systems.
for patch namespaces: it should enable users to use two different 
externals/abstractions with the same name in two different patches.
patch1: declare -lib version1/myabs
patch2: declare -lib version2/myabs
I think namespaces should be expanded to abstractions and not the other 
way around (currently it is the other way round. I guess because 
abstractions are loaded before. right now declares in abstractions get 

IOhannes m zmoelnig wrote:
> use-case#1 (Pd-vanilla)
>   extra/mylib/mylib.dll (containing [mobj1])
>   extra/mylib/myobj1-help.pd
>   .
>   you load "mylib", e.g. by doing so on startup (-lib), or by instanting 
> [mylib].
>   you create [myobj1], right-click on help and myobj1-help.pd opens up

problem: you don't want to load all libraries into memory, which is a 
waste of resources.

> use-case#2 (Pd-vanilla)
>   extra/mylib/myobj1.dll
>   extra/mylib/myobj1-help.pd
>   .
>   you 'load' "mylib" by adding it to the path, either on startup or with 
> [declare]
>   you create [myobj1], right-click on help and myobj1-help.pd opens up

this is what I suggested, too, but it seems broken (at least on os x it 
does nothing). the -path at startup works, but does not provide local 
namespace. and it will not work with abbreviated objects.

> use-case#3 (Pd-vanilla)
>   extra/mylib/myobj1.dll
>   extra/mylib/myobj1-help.pd
>   .
>   you create [mylib/myobj1], right-click on help and myobj1-help.pd opens up

that's the ugly thing that I want to avoid like hell. btw. with one of 
declare or import(?) I had the problem, that when I loaded a library 
into the namespace, then mylib/myobj1 could not be created any more, 
only myobj1.

> use-case#4 (only Pd-extended)
>   extra/mylib/mylib.pd
>   extra/mylib/myobj1.dll
>   .
>   you load "mylib" by using [import mylib]
>   you create [myobj1], right-click on help and myobj1-help.pd opens up

afaict this is broken.

> i still don't see what is provided by [import] that is not provided by 
> Pd-vanilla anyhow.

the possibility to printout the libs and paths

> the good thing about use-cases#1-#3 is, that they will work on both 
> Pd-vanilla and Pd-extended.
> and if [declare] is broken, then it should be fixed.

it is broken and it should be fixed. but I read that miller gave up on 
this for 0.41???

More information about the Pd-list mailing list