On Sat, Oct 8, 2011 at 4:51 PM, Hans-Christoph Steiner hans@at.or.at wrote:
And yes, vanilla/ is an experiment in splitting out the internals into a library. This allows people to write highly optimized versions of it for specific situations, like specific CPUs, and then use and distribute them easily.
Ah, I see. If loaded, vanilla/ takes precedence over the corresponding core class definitions. I noticed classes like sqrt~ which have double-incompatible definitions so vanilla/ requires some modifications. Further I would like to work on cyclone as there are Hoeldrich style routines in it. I'll send an SVN write access request to the dev list, for these modules to start with.
Katja
On Oct 9, 2011, at 5:22 AM, katja wrote:
On Sat, Oct 8, 2011 at 4:51 PM, Hans-Christoph Steiner hans@at.or.at wrote:
And yes, vanilla/ is an experiment in splitting out the internals into a library. This allows people to write highly optimized versions of it for specific situations, like specific CPUs, and then use and distribute them easily.
Ah, I see. If loaded, vanilla/ takes precedence over the corresponding core class definitions. I noticed classes like sqrt~ which have double-incompatible definitions so vanilla/ requires some modifications. Further I would like to work on cyclone as there are Hoeldrich style routines in it. I'll send an SVN write access request to the dev list, for these modules to start with.
With pd-double, the vanilla/ lib won't take precedence because the internals are still statically linked in and their setup() functions are called at startup. The only way to access the vanilla/ objects in pd-double is with a vanilla/ prefix.
I keep vanilla/ lib sources in sync with Pd so its maintenance load is minimal. So once pd-vanilla has double-precision support, vanilla/ lib will too
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-
Hans-Christoph Steiner -
katja