On Mon, 2023-06-05 at 11:46 +0200, Miller Puckette wrote: Pdouble?
Pd?
pdpd?
enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com
For me pd64 gives more chances of confusion than pdd or pdpd.
Apart from the name of the app we should try to give this new app as much separation of Pd's paths and preferences as we can.
Starting with a new name of the app seems the most sane.
--
Mensaje telepatico asistido por maquinas.
On 05/06/2023 14:23, Dan Wilcox wrote:
On Mon, 2023-06-05 at 11:46 +0200, Miller Puckette wrote: Pdouble?
Pd?
pdpd?
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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. I think that confusion with 64 bit architectures will become less present, since nowadays most (all?) major platforms are based on 64 bit CPUs. So "64 bit" is just a particular taste of CPUs, as in x86_64 or arm64, which has no direct impact from the user's point of view. If you want to work with 64bit-wide data on a 32bit PPC, you just need Pd64-PPC32, on arm64 it will be Pd64-arm64.
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). I quite like Pd² or even Pd2, though.
.
Funnily, my personal feeling is the opposite :-) I feel that Pd64 clearly describes Pd working with 64 bit data.
I myself don't have any trouble with whatever name we use as I know perfectly well the situation. My trouble with Pd64 is that it will get listed next to Pd in almost any package manager and may be many people opt Pd64 (thinking that is the one for 64bit cpus)
Pd2 is also a good one.
--
Mensaje telepatico asistido por maquinas.
On 07/06/2023 07: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. I think that confusion with 64 bit architectures will become less present, since nowadays most (all?) major platforms are based on 64 bit CPUs. So "64 bit" is just a particular taste of CPUs, as in x86_64 or arm64, which has no direct impact from the user's point of view. If you want to work with 64bit-wide data on a 32bit PPC, you just need Pd64-PPC32, on arm64 it will be Pd64-arm64.
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). I quite like Pd² or even Pd2, though.
.
My trouble with Pd64 is that it will get listed next to Pd in almost any package manager and may be many people opt Pd64 (thinking that is the one for 64bit cpus)
I think almost all (recent) package managers no longer offer 32bit-CPU packages?...
Antoine
Le mer. 7 juin 2023 à 13:08, Lucas Cordiviola lucarda27@hotmail.com a écrit :
Funnily, my personal feeling is the opposite :-) I feel that Pd64 clearly describes Pd working with 64 bit data.
I myself don't have any trouble with whatever name we use as I know perfectly well the situation. My trouble with Pd64 is that it will get listed next to Pd in almost any package manager and may be many people opt Pd64 (thinking that is the one for 64bit cpus)
Pd2 is also a good one.
--
Mensaje telepatico asistido por maquinas.
On 07/06/2023 07: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. I think that confusion with 64 bit architectures will become less present, since nowadays most (all?) major platforms are based on 64 bit CPUs. So "64 bit" is just a particular taste of CPUs, as in x86_64 or arm64, which has no direct impact from the user's point of view. If you want to work with 64bit-wide data on a 32bit PPC, you just need Pd64-PPC32, on arm64 it will be Pd64-arm64.
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). I quite like Pd² or even Pd2, though.
.
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
gasdm IOhannes
Em qua., 7 de jun. de 2023 às 11:43, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
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.
yeah, I agree, just like now it has pd 32 bit application and pd 64 bit application over there and they both are named the same. I don't see a good reason to have a different name for the double precision version and I think this is the one that will be the modern and "good one"... the others will be there for compatibility to old externals and patches I guess.
- 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)
can't say anything about this.
- then there's the binary you run on your computer
I remember that at first, when it was all fresh news, the 64 bit had a different name, now it's the 32 bit that has a different name. We could have a phase where 'double' is marked.
for reference, pd ceammc already is available for double precision and they mark the double precision version as 'double', at least on the download section on github, for reference ===> https://github.com/uliss/pure-data/releases/tag/v2023.02
cheers
gasdm IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hello,
My preference ist to name of binary pd double precision:
pd
- since all my scripts calling pd can use double precision if I install it instead of pd.
- most want just double precision or not
- the ones with need of both, can hold them in seperate pathes like "dp/pd", "sp/pd", ...
atb winfried
Am Mittwoch, 7. Juni 2023, 16:42:53 CEST schrieb IOhannes m zmoelnig:
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
gasdm IOhannes
-
Alexandre Torres Porres -
Antoine Rousseau -
Dan Wilcox -
IOhannes m zmoelnig -
Lucas Cordiviola -
Winfried Ritsch