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-debi...
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra