so now that Pd-0.54 is out, I wonder whether we have settled on "pd64" being the "official" name for double-precision binaries.
the question mostly arises from an flext issue [54] that i recently raised: flext can be built as a dynamic library, which is called libflext-pd.so (for Pd obviously). since flext can only handle a single floatsize, we would need a different dylib name for the double-precision variant of Pd, and i suggested libflext-pd64.so as thomas has rightfully pointed out, this would only make sense if "pd64" is indeed the agreed-on name of the double-precision Pd binary.
so: is it?
afaict there has been rough consensus about this from all vocal parties; however miller has not said anything beyond the initial "Pdouble".
mgfasdr IOhannes
PS: this is really about the names of the executable files (/usr/bin/pd64, .../pd/bin/pd64.exe, .../pd/bin/pd64.dll). i think this *can* be kept distinct from the "marketing name" (e.g. what is announced on websites), but of course it need not be.
PPS: and yes, as indicated in previous mails, Debian now ships a puredata64 package which includes a /usr/bin/pd64 binary; which is all my doing (so you know who is to blame). while this sets a precedent, I don't think it is too late to change the name (even though I would rather not :-))
I think pd64 is fine - however, it would be wise when distributing it to emphasize that it's 64 bit samples, not 64 bit architecture.
I'm pretty sure people will get confused by that.
cheers
Miller
On 7/25/23 08:32, IOhannes m zmoelnig wrote:
so now that Pd-0.54 is out, I wonder whether we have settled on "pd64" being the "official" name for double-precision binaries.
the question mostly arises from an flext issue [54] that i recently raised: flext can be built as a dynamic library, which is called libflext-pd.so (for Pd obviously). since flext can only handle a single floatsize, we would need a different dylib name for the double-precision variant of Pd, and i suggested libflext-pd64.so as thomas has rightfully pointed out, this would only make sense if "pd64" is indeed the agreed-on name of the double-precision Pd binary.
so: is it?
afaict there has been rough consensus about this from all vocal parties; however miller has not said anything beyond the initial "Pdouble".
mgfasdr IOhannes
PS: this is really about the names of the executable files (/usr/bin/pd64, .../pd/bin/pd64.exe, .../pd/bin/pd64.dll). i think this *can* be kept distinct from the "marketing name" (e.g. what is announced on websites), but of course it need not be.
PPS: and yes, as indicated in previous mails, Debian now ships a puredata64 package which includes a /usr/bin/pd64 binary; which is all my doing (so you know who is to blame). while this sets a precedent, I don't think it is too late to change the name (even though I would rather not :-))
[54] https://github.com/grrrr/flext/issues/54
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 7/25/23 17:37, Miller Puckette wrote:
I think pd64 is fine - however, it would be wise when distributing it to emphasize that it's 64 bit samples, not 64 bit architecture.
yes.
the tagline of the "puredata64" Debian package therefore reads:
realtime computer music and graphics system (double precision)
mgfsdr IOhannes
-
IOhannes m zmoelnig -
Miller Puckette