[PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hans-Christoph Steiner
hans at eds.org
Tue Feb 17 19:43:02 CET 2009
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
More information about the Pd-dev
mailing list