[PD] Using [import] [was: Re: sending OSC bundles. + help files?]
Hans-Christoph Steiner
hans at eds.org
Sat Sep 13 06:57:24 CEST 2008
On Sep 12, 2008, at 4:40 PM, Phil Stone wrote:
> Hans-Christoph Steiner wrote:
>> On Sep 12, 2008, at 2:45 PM, 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. ;)
>>>
>>
>> Or even easier, just copy the "mrpeach" folder in extra from a Pd-
>> extended build into your Pd-vanilla install's extra folder. Done.
>> Then you can use namespace prefixes too, like [mrpeach/routeOSC].
>>
>> .hc
>>
>>
>
> Yes, but the [import mrpeach] objects would throw errors, unless the
> pure-Pd end-user created empty [import] objects, as Frank pointed out.
> There doesn't seem to be a solution that is "one-size-fits-all."
>
>
> I know that the namespace problem in general is still under
> construction, and I'm happy to have [import], but it would be nice if
> there weren't such an incompatibility with vanilla Pd. Is there any
> chance that [declare] could be the solution for both builds -- what
> obstacles are there to that?
If Miller accepts the patches to [declare], then it would work in
vanilla.
.hc
>
>
> Phil
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
------------------------------------------------------------------------
----
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
More information about the Pd-list
mailing list