Frank Barknecht wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?
no
AFAIK [import] is an external, for vanilla users it would just be an additional dependency to install.
Another problem, maybe bigger problem, is that using [import] like in pd-extended requires a certain directory layout. For example to make
well, not really; the user just assumes a certain directory layout; due to loads of fallbacks you might not notice that you have a different layout in several cases (in others you might have weird effects though)
[import mrpeach] work in that it makes [routeOSC] availabe, pd-vanilla users not only need [import], they also have to put routeOSC.pd_linux|dll|... into a directory "mrpeach" in their path (e.g. into "extra") to let [import mrpeach] actually load [routeOSC].
well, yes and now. as said above, there is always the fallback thing. having [import mrpeach] without a "mrpeach" directory will (at the worst) give you a warning (or error?). nevertheless Pd will still find [routeOSC] if it lives in extra/ (or somewhere else in the path of pd)
on pd-vanilla you could either get the "import"-external, make a dummy [import], or just ignore the error about "import".
this all sounds much more complicated than it is.
But the problem is not as big as I make it. E.g. vanilla users could use an empty abstraction import.pd and keep Martin's objects in the Pd-path directly. They are available as [routeOSC],... directly then. Having the empty import.pd will make Pd shut up when [import mrpeach] is used and you could use [routeOSC] without prefix just fine. You could not use [mrpeach/routeOSC] then, but you don't want to anyway. ;)
imho, using things like [mrpeach/routeOSC] is the way to break your patches second most surely. using [import] should give you the least trouble (until [declare] is somehow workable!)
fgmadsfr IOhannes