[PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

[Hans-Christoph Steiner]

On Feb 17, 2009, at 2:37 AM, Roman Haefeli wrote:

> On Tue, 2009-02-17 at 00:36 -0500, Matt Barber wrote:
>>> Getting rid of cyclone's pow~ would break all of the patches that  
>>> rely
>>> on cyclone's pow~, and would also make it harder to import Max/MSP
>>> patches.  Removing it is not a solution.
>>
>>
>> Okay.  But I don't see why something that is a rather obvious breach
>> of style should be allowed to bully the rest of the application.  I
>> have never used Max/MSP, but it seems like its (and cyclone's) [pow~]
>> is really something more like an [exp~] with a changeable base.
>>
>> In my view -- this is an open-source program which is more or less
>> guaranteed to evolve.  If your patch breaks with a new version, use  
>> an
>> older version, or find and fix the problems in the patch.  To me it  
>> is
>> a problem to avoid improvements to the language to maintain backward
>> compatibility at all costs, and much better to throw warnings --
>> "Warning: your patch might be broken: look for all instances of pow~.
>> Thank you."  =o)
>>
>> The best solution in any of these circumstances is the least worst
>> solution.  As far as I can tell the least worst solution is the one
>> with the most patch-level control for the libraries.  As a user I
>> would rather do the research to see which externals I needed than to
>> be forced into accepting one or the other, ESPECIALLY if vanilla
>> classes are overwritten -- this seems the most egregious to me.
>> Pd+libs and Pd-extended should support vanilla patching, since many
>> users insist upon vanilla only -- worrying about cyclone and allowing
>> vanilla to break seems to me to be putting the cart before the horse
>> with regard to backward compatibility.  Pd is not Max/MSP.  Should  
>> you
>> really have to import vanilla?
>>
>> Thanks,
>
>
> yo.. i very much agree with you. isn't it the wrong approach to use so
> many tricks and kludges just to keep backwards compatibility? isn't  
> that
> just a too expensive goal?
>
> i mean, there have been so many discussions about how to load  
> libraries,
> extend namespaces and such and then there is much not working yet,
> respectively there are still a lot of incompatibilies between
> pd-extended and pd vanilla, is it wise to introduce _now_ such a
> feature? for me it is clearly another step away from a more consistent
> pd world. and i am a bit confused to see, that this is done
> deliberately.
>
> roman

I don't know of any incompatibilities between Pd-vanilla and Pd- 
extended in this regard.  The incompability here is between the old  
cyclone pow~ which has been around for a long time, and Pd-vanilla  
0.42's pow~.  In the bigger sense, the library incompatibilities  
between Pd-extended and some builds of Pd-vanilla come from the  
different library formats. If you build Pd-vanilla with the same  
library format at Pd-extended, then it'll all be compatible.  There  
isn't a standard way to include libraries in Pd-vanilla, so there are  
bound to be incompatibilities between different installations.

Try it yourself:

http://autobuild.puredata.info/auto-build/latest/Pd-0.42.4-vanilla+libs-debian-stable-i386.deb

.hc


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

Computer science is no more related to the computer than astronomy is  
related to the telescope.      -Edsger Dykstra