Personally, as this affects fundamental objects, I would do both. As this can be a workflow issue, my thinking is:
* Assume vast majority of users & use cases want fixed behavior (or don't particularly care), so update objects to use new/fixed behavior by default.
* Add a compatibility flag for older projects which *rely* on older behavior for *all* instances of the objects.
* Add a creation argument to the objects for those cases where people rely on the old behavior for certain situations, but also want the newer behavior for most other instances.
* Document the old versus new behavior in a help-patch subpath with comparisons.
On Aug 5, 2021, at 10:55 AM, pd-dev-request@lists.iem.at wrote:
Date: Thu, 5 Aug 2021 10:55:38 +0200 From: Max <abonnements@revolwear.com mailto:abonnements@revolwear.com> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] plans for next Pd release Message-ID: <265a5773-2750-af8b-22a5-d01bdc4f6483@revolwear.com mailto:265a5773-2750-af8b-22a5-d01bdc4f6483@revolwear.com> Content-Type: text/plain; charset=utf-8; format=flowed
On 05.08.21 03:56, Miller Puckette via Pd-dev wrote:
I'm using that as rarely as I can, so far only for bug fixes. I don't think a limit on numerical accuracy is exactly a bug. I think it's nicer to most users not to have them have to bother with specifying a compatibility version.
Maybe make the numerical accuracy a settable variable with the current depth as a default? (bonus: instant bitcrusher effect)
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/