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.
Date: Thu, 5 Aug 2021 10:55:38 +0200From: Max <abonnements@revolwear.com>To: pd-dev@lists.iem.atSubject: Re: [PD-dev] plans for next Pd releaseMessage-ID: <265a5773-2750-af8b-22a5-d01bdc4f6483@revolwear.com>Content-Type: text/plain; charset=utf-8; format=flowedOn 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)