Yeah, after batting names around, I think "pd64" is the simplest even if it potentially runs into architecture naming. It's definitely true we are well past the 32 - 64 bit transition at this point anyway. If it worked for CSound it can work for us and, really, most other naming is clunky IMO. This just needs a good explanation so the usage of 64 is clear: 64-bit double precision floats and support for very long sound files (via CAF).
> On Jun 8, 2023, at 11:15 AM, [email protected] wrote: > > Message: 1 > Date: Wed, 7 Jun 2023 16:42:53 +0200 > From: IOhannes m zmoelnig <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] double precision pd? > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/7/23 12:55, Antoine Rousseau wrote: >> Le mer. 7 juin 2023 ? 10:47, Lucas Cordiviola <[email protected] >> <mailto:[email protected]>> a >> ?crit : >> >>> For me pd64 gives more chances of confusion than pdd or pdpd. >>> >> (...) >> >>> Starting with a new name of the app seems the most sane. >>> >> >> Funnily, my personal feeling is the opposite :-) >> I feel that Pd64 clearly describes Pd working with 64 bit data. > [...] >> >> To me, "pdd" or "pdpd" really sound like different apps, which I find a bit >> strange (it's actually the same app, only different options). > > that's also my personal feeling. > > double-precision Pd ist just a variant, and pdpd is hard to read (once > you leave the Pd universe). > > on my system i can install "libpdl, libpdb-redo, libpda-* packages, and > I'm not overly enthusiastic about finding a "libpdpd" in this list. > probably the library version is not so important, so with applications > it is: "pdal, pdd, pdf, pdl, pdb", and having a "pdpd" in there seems > also hard to sport. > > my brain is just faster with keeping number (like "64" or "2") apart > from alpha-chars... > > >> I quite like Pd? or even Pd2, though. > > i like them too, esp the "Pd?" looks good and has a nice ring, but of > course this is not an ASCII-compatible name and thus a no go. > > with Pd2, i guess people will wonder when they missed the v1.0 release > of Pd though (something I don't see happening with Pd64). > > > as a reference, the venerable Csound (which i think has been using > double precision as the internal data representation for >10 years no), > is (still) using csound64 (as in "csound64.dll") for the > double-precision (even though it no longer offers any single-precision > variant). > afaict this is independent from "64bit architecture" (but it seems they > no longer provide any 32bit architecture downloads (e.g. for Win32)) > > so in the long run, i think that 32bit architectures will no longer be > relevant on any download page (i guess the only 32bit architecture that > will stay relevant for some time is armv8; but there are no downloadable > binaries on any homepage anyhow; and a package manager like "apt" picks > the "correct" version of Pd anyhow) > > > i think one of the questions is, where the name will actually be exposed. > > - of course, the webpage (https://msp.ucsd.edu/, https://puredata.info/) > cou use whatever descriptive name to lure the people into downloading > the right package. > - personally I'm mostly concerned with package managers (and as said > above: all package managers I know of have a way to handle the > architecture (amd64, i386) more or less transparently) > - then there's the binary you run on your computer -------- 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
