[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