[PD] rj dirlib [was: Re: how to nqpoly?]

[Hans-Christoph Steiner]

On Nov 9, 2009, at 2:42 PM, Claude Heiland-Allen wrote:

> Hans-Christoph Steiner wrote:
>> This is what we saw with the introduction of [pow~] to Pd-vanilla.   
>> Many people were using cyclone's [pow~] before.  Since Pd-vanilla's  
>> pow~ is built into the pd binary, there is no way to use an  
>> abstraction called 'pow~.pd', and it even overrides pow~.pd_linux.
>
> Sure, but can't you still use -lib to load your own pow~.d_fat in Pd  
> since 0.42 (which would print "warning: renamed old pow~ to  
> pow~_aliased" or similar)?  Or am I completely missing the meaning  
> of those printouts?

I am not positive how that mechanism works. Based on my understanding  
of it, you could force it to load a particular object class (i.e.  
cyclone's pow~) using the pd -lib technique you mention, provided that  
object class is a binary, and not an abstraction.  If the problem  
involved an abstraction being overridden by a pd internal, you are  
shit-out-of-luck.

So its not really a solution to the aforementioned problem.  There are  
other issues with that aliasing technique as discussed in the  
archives.  For these reasons, the auto-aliasing is disabled in Pd- 
extended 0.42.5, but we still need to figure out how to deal with the  
new pd-internal [pow~] and its conflict with cyclone's [pow~].

>> The only way to maintain compatibility that has been proven is to  
>> use the same versions of everything.
>
> Exactly - no need to care too much about backwards compatibility,  
> because you could always use pd-0.38-devel for your old patches and  
> pd-0.43-guirewrite for your current patches and pd-0.44 for your  
> next decade patches...
>
> The missing piece here is an auto-upgrade tool for pd patches,  
> similar to what lilypond uses:
>
> http://lilypond.org/doc/v2.9/Documentation/user/lilypond/Updating-files-with-convert_002dly


Personally, I think we can improve the situation quite a bit, that's  
why I wrote that paper for PdCon.  Of course, sticking to the same  
versions of everything is the only guarantee, but we can do a lot to  
avoid incompatibilities.

The simplest one is making it so that externals and abstractions  
included in the same folder as a patch have precedence over all  
others, including pd-internals.  That way you can stick your own  
[pow~] in the same folder as your project, and you'll always know its  
your [pow~] in use.

.hc



----------------------------------------------------------------------------

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie