Frank Barknecht wrote: > Hallo, > Phil Stone hat gesagt: // Phil Stone wrote: > > >> I apologize for following-up my own post, but this is a fairly important >> point, and I think it needs clarification. I'm about to release an >> abstraction, and I used [import] to eliminate a few dozen [mrpeach/...] >> style invocations of Martin Peach's OSC objects. Up until now, my >> abstraction would work with vanilla Pd if a couple of externals/libs >> were included (mrpeach being one of them). Have I now completely >> blocked out any vanilla Pd users by using [import]? >> > > 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 > [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]. > > 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. ;) >
Well, it's a little more complicated than one would wish, but at least it's possible, then. Thanks, Frank. Phil _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
