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, [email protected] wrote: > > Date: Thu, 5 Aug 2021 10:55:38 +0200 > From: Max <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] plans for next Pd release > Message-ID: <[email protected] > <mailto:[email protected]>> > 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/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
