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

[Matt Barber]

>> i think, that the question, why a new object [pack] is named pack is not
>> rhetoric at all and isn't answered yet. so lets go again: why is [pack]
>> from zexy called [pack]?
>>
>
> because it is meant as a fully backwards-compatible replacement of [pack],
> with added features.
> since i have been repeating this for several times now, i would be
> interested in the precise part of the above sentence that is unclear to you.
>


Perhaps there is a conceptual difference between overriding internal
classes for a class with the same behavior but with added methods
(e.g. the [print] and [soundfiler] examples from before), and
overriding with a different object, or one with a different interface
(the [pow~] situation).

For instance I think it would be at least a well-motivated task to
write over [tabread4~] with one that inherited everything vanilla
[tabread4~] could do, did those by default, but added methods for
Hermite interpolation instead of Lagrange.  Meanwhile, it would not be
well-motivated to override it with an object which (to be silly)
indexed tables in reverse, or (to be ridiculous because it's 4:00 AM
here) grabbed a random joke from the web every 64 samples and posted
it to the console.

What's unclear -- and to me probably the most important to solve as a
result of this thread -- is what to do when vanilla adds features
which potentially clash with objects in existing libraries.  After
all, this would be a much shorter thread if the problem were in a new
[rfft~] object from some library that output bins in the order they
appear in SuperCollider, thus breaking vanilla [rfft~] patches every
time that library was loaded -- "in the name of gbuzz stop what you're
doing and fix the library!"