Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
So PD would become ... PDX. Oh well. Tacky.
Message: 1 Date: Mon, 23 Nov 2020 15:51:11 +0100 From: Allister Sinclair allistersinclair@gmail.com To: Martin Peach chakekatzil@gmail.com Cc: Dan Wilcox danomatika@gmail.com, Pd-List pd-list@lists.iem.at Subject: Re: [PD] Pd 64 bits precision "for real"? Message-ID: CALx3ts3AJaA7zkYf3wFzJPWzbDjchMW53gq_H_YFgpgMpBCijA@mail.gmail.com Content-Type: text/plain; charset="utf-8"
but they're already at gpt3
Le lun. 23 nov. 2020 à 15:45, Martin Peach chakekatzil@gmail.com a écrit :
or dippidydoo, dpd2
On Mon, Nov 23, 2020 at 7:24 AM Dan Wilcox danomatika@gmail.com wrote:
I think "pd64" is fine, otherwise the list get's catchy/dumb:
pdpd (haha) pd two-times pd again pd double trouble pd dubs' pd-sharp (less rounding) ...
I would fine "dppd" confusing unless we go ahead and re-brand ala "pd
vanilla" and "double-dipped pd" aka "dppd"...
On Nov 23, 2020, at 12:00 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Mon, 23 Nov 2020 09:22:49 +0100 From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@lists.iem.at Subject: Re: [PD] Pd 64 bits precision "for real"? Message-ID: 57e459d6-e8d1-516c-da37-af88912aaf21@iem.at Content-Type: text/plain; charset=utf-8; format=flowed
On 11/23/20 12:25 AM, Martin Peach wrote:
It should be named dppd to avoid confusion imho.
or pddp (or is that already taken?)
when csound switched to double precision they renamed things to "csound64" (with "things" being at least the libraries that hold the engine).
so i like pd64 better, as it is obvious that this is still Pd (and not just some nice palindromic acronym).
but anyhow, yes: we probably need a catchy name.
fgmadsr IOhannes
On Tue, Nov 24, 2020 at 5:07 AM jayrope jayrope@gmail.com wrote:
Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because all the memory structures would be differently sized, so any externals built for previous versions would crash. While any patches using vanilla objects would still work, unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
unless a 64-bit version had some way of running 32-bit externals
Pleeease, let's not call it "64-bit" vs. "32-bit". Those terms usually refer to the CPU target architecture. It's "single precision" vs. "double precision"
so any externals built for previous versions would crash
IOhannes added a clever mechanism to avoid runtime crashes. Incompatible externals will instead refuse to load.
What we need is to find an easy way to create "fat" binaries (containing both single and double precision of the same library) and/or come up with a naming convention, so both versions can co-exist (similar to how we use ".*_amd64" and ".*_i386" to distinguish between 64-bit and 32-bit Intel binaries).
it would be effectively a different program, not just a new version.
I would say it's neither. It's just a build option.
Christof
On 24.11.2020 16:07, Martin Peach wrote:
On Tue, Nov 24, 2020 at 5:07 AM jayrope jayrope@gmail.com wrote:
Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because all the memory structures would be differently sized, so any externals built for previous versions would crash. While any patches using vanilla objects would still work, unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I think of it as a variant. It's the same program but with 64 bit precision.
Just like we have the section "*Compiled versions for older, 32-bit processors*" for download in miller's site. As far as externals go, those have the same problem and one would need to get pd 32 bits just to run old external libraries not available for the newer Pd. One example is the [hid] external that we just now made available (finally).
And in the end if we have downloads for Pd 0.52-0 in 64 bit precision, then it'd be Pd 0.52-0 just like the one with Pd with 32 bit precision...
So yeah, I guess we need to make it available for download for 32 bits precision as well, just like we should keep the ones for 32 bit processors and even for PPC (although no new versions will be made available I guess as miller's machine broke, so probably not).
So, just make a section "*Compiled with double (64-bit) precision*" and another as "*Compiled with single (32-bit) precision*"
As for how the app comes out. I remember that when it was something new, the ones compiled for 64-bit processors had a different name. Now it's the other way around. For example, the mac one comes as "i386" at the end of the app name!
We can just have something like that and start by making a distinction, with something like Pd-0.52-0-double, and some time in the future (up to 3 versions later the most, I guess) it'll be the "regular" one and the others can be called Pd-0.55-0-single.
cheers
Em ter., 24 de nov. de 2020 às 12:21, Christof Ressi info@christofressi.com escreveu:
unless a 64-bit version had some way of running 32-bit externals
Pleeease, let's not call it "64-bit" vs. "32-bit". Those terms usually refer to the CPU target architecture. It's "single precision" vs. "double precision"
so any externals built for previous versions would crash
IOhannes added a clever mechanism to avoid runtime crashes. Incompatible externals will instead refuse to load.
What we need is to find an easy way to create "fat" binaries (containing both single and double precision of the same library) and/or come up with a naming convention, so both versions can co-exist (similar to how we use ".*_amd64" and ".*_i386" to distinguish between 64-bit and 32-bit Intel binaries).
it would be effectively a different program, not just a new version.
I would say it's neither. It's just a build option.
Christof
On 24.11.2020 16:07, Martin Peach wrote:
On Tue, Nov 24, 2020 at 5:07 AM jayrope jayrope@gmail.com wrote:
Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because all the memory structures would be differently sized, so any externals built for previous versions would crash. While any patches using vanilla objects would still work, unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thank you Martin,
so it does behave similar to OS9 versus OSX. Well then, PDX or PD64.
I'd very much prefer for backwards compatibility, but double precision is the way to go for better sound.
I suppose there'll be a way to import old patches? Export new patches to 32bit pd?
Both would really help to work on with present hardware (libpd-based) for instance.
I hope i didn't miss this info in digests sent before. Get's a bit hard to follow all of this sometimes.
Thank you again
On 11/24/20 16:07, Martin Peach wrote:
On Tue, Nov 24, 2020 at 5:07 AM jayrope jayrope@gmail.com wrote:
Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because all the memory structures would be differently sized, so any externals built for previous versions would crash. While any patches using vanilla objects would still work, unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
I'd very much prefer for backwards compatibility, but double precision is the way to go for better sound.
Double precision is no silver-bullet. Double precision Pd needs more memory and can run slower on certain platforms (for several reasons).
I suppose there'll be a way to import old patches? Export new patches to 32bit pd?
Pd patches are not affected, they are just text files. It's really only about existing externals. Once you have your externals compiled for double precision, existing projects will work.
Christof
On 24.11.2020 17:28, jayrope wrote:
Thank you Martin,
so it does behave similar to OS9 versus OSX. Well then, PDX or PD64.
I'd very much prefer for backwards compatibility, but double precision is the way to go for better sound.
I suppose there'll be a way to import old patches? Export new patches to 32bit pd?
Both would really help to work on with present hardware (libpd-based) for instance.
I hope i didn't miss this info in digests sent before. Get's a bit hard to follow all of this sometimes.
Thank you again
On 11/24/20 16:07, Martin Peach wrote:
On Tue, Nov 24, 2020 at 5:07 AM jayrope jayrope@gmail.com wrote:
Why do we need _any_ name change? Any obvious version jump would do it already, 0.6, no?
A 64-bit Pd would not be compatible with any previous version because all the memory structures would be differently sized, so any externals built for previous versions would crash. While any patches using vanilla objects would still work, unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 24. November 2020 17:28:45 MEZ schrieb jayrope jayrope@gmail.com:
Thank you Martin,
so it does behave similar to OS9 versus OSX. Well then, PDX or PD64.
I'd very much prefer for backwards compatibility, but double precision is the way to go for better sound.
I suppose there'll be a way to import old patches? Export new patches to 32bit pd?
as Christof already said, patches are blissfully unaware of Pd's number representation (whether it's single or double precision). they are even unaware of the processor architecture! (hey you can run a Pd patch created on win10 on a raspberry pi!)
there won't be a way to just "save" externals with doubles precision support. they need explicit recompilation.
mfg.hft.fsl IOhannes
Em ter., 24 de nov. de 2020 às 12:09, Martin Peach chakekatzil@gmail.com escreveu:
unless a 64-bit version had some way of running 32-bit externals in parallel, it would be effectively a different program, not just a new version.
Martin
forgot to quote this, my last email was responding to this
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmölnig -
jayrope -
Martin Peach