On Feb 16, 2009, at 4:58 PM, Frank Barknecht wrote:
Hallo, Matt Barber hat gesagt: // Matt Barber wrote:
At least we know it was an intentional difference:
http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html
For extended would it be possible to exclude cyclone pow~ from the library, or less drastically patch both cyclone and vanilla pow~ to throw a warning, as was discussed last april?
This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a "-lib" loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names.
Cyclone in pd-extended is just a libdir library of Max/MSP compatible objectclasses. When cyclone is built as one big library in one file, then there are some extra Max/MSP compatibility features. If someone added the cyclone.pd_linux creation to the Pd-extended build system, then this would also be included.
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.
.hc
Running "pd-0.42 -lib cyclone" gives this:
... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ...
and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually.
Unfortunatly you cannot use the other cyclone objects without rewriting [pow~] when cyclone is loaded as a library.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams