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, pd-dev-request@lists.iem.at wrote:

Message: 1
Date: Wed, 7 Jun 2023 16:42:53 +0200
From: IOhannes m zmoelnig <zmoelnig@iem.at>
To: pd-dev@lists.iem.at
Subject: Re: [PD-dev] double precision pd?
Message-ID: <5cf4aa6d-c70e-8fd3-993a-e4d1b49d1f89@iem.at>
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 <lucarda27@hotmail.com> 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
danomatika.com
robotcowboy.com