[PD] sending OSC bundles. + help files?

[Phil Stone]

Phil Stone wrote:
> Hans-Christoph Steiner wrote:
>   
>> The idea is to embed the library settings into the patch.  In  
>> Pd-0.40.3-extended, if you added this to the patch, it would work for  
>> any Pd-0.40.3-extended install:
>>
>> [import mrpeach]
>>
>> Or could use Miller's declare, but I don't remember what the state of  
>> the declare bugs were in 0.41.4.  It would be something like:
>>
>> [declare -lib mrpeach]
>>
>> or maybe
>>
>> [declare -stdpath extra/mrpeach]
>>
>> .hc
>>   
>>     
>
> Just to be clear, does this mean if I use [import] in a patch, it 
> becomes incompatible with vanilla Pd?  Or can [import] be um, imported 
> into vanilla Pd?
>   

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]?

Of course, I could use [declare], but I've seen some questions about 
[declare] bugs on this list.

Is my only choice to go back to the redundant (and rather ugly) 
[mrpeach/routeOSC] style, in order to be compatible with vanilla Pd?

Is it rude to ask why we are essentially forking a very useful object?  
Is there any possibility of this being resolved into one, compatible object?


Phil Stone
www.pkstonemusic.com