Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
On Nov 20, 2020, at 8:17 PM, pd-list-request@lists.iem.at wrote:
Message: 2 Date: Fri, 20 Nov 2020 14:16:45 -0300 From: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: [PD] Pd 64 bits precision "for real"? Message-ID: <CAEAsFmi2xraTaNURCXWJPeJgEmLxEoD80NLRBAr-ztZhXEdRLw@mail.gmail.com mailto:CAEAsFmi2xraTaNURCXWJPeJgEmLxEoD80NLRBAr-ztZhXEdRLw@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi there, it's known Pd can be built with 64 bits precision, but when can we expect it to also be available for download as such?
I'm currently working on externals that play large files without running into precision issues, but that'd be unnecessary once Pd 64 bits is more of a thing.
It seems to me all should be good to go once it's already possible for those who compile it like that... so I guess the main issue would be with externals that also need to be compiled for that.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Cool, thanks!
Em sex., 20 de nov. de 2020 às 19:18, Dan Wilcox danomatika@gmail.com escreveu:
Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
On Nov 20, 2020, at 8:17 PM, pd-list-request@lists.iem.at wrote:
Message: 2 Date: Fri, 20 Nov 2020 14:16:45 -0300 From: Alexandre Torres Porres porres@gmail.com To: Pd-List pd-list@lists.iem.at Subject: [PD] Pd 64 bits precision "for real"? Message-ID: CAEAsFmi2xraTaNURCXWJPeJgEmLxEoD80NLRBAr-ztZhXEdRLw@mail.gmail.com Content-Type: text/plain; charset="utf-8"
Hi there, it's known Pd can be built with 64 bits precision, but when can we expect it to also be available for download as such?
I'm currently working on externals that play large files without running into precision issues, but that'd be unnecessary once Pd 64 bits is more of a thing.
It seems to me all should be good to go once it's already possible for those who compile it like that... so I guess the main issue would be with externals that also need to be compiled for that.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
Dan, is this in any way related with buffer indexing? I am wondering if with 64bit Pd the B16.long-varispeed.pd workaround with the second inlet will still be necessary to get cleaner table playback at slow speeds?
thanks, P
Double precision Pd indeed solves the table playback issue (among other things).
Christof
PS: "64-bit Pd" usually means Pd compiled for a 64-bit architecture, but this thread is really about double precision Pd. I'm sure you were talking about the latter, but this is a constant source of confusion, so I thought I'd better make this clear for other readers.
On 22.11.2020 23:39, Peter P. wrote:
- Dan Wilcox danomatika@gmail.com [2020-11-20 23:19]:
Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
Dan, is this in any way related with buffer indexing? I am wondering if with 64bit Pd the B16.long-varispeed.pd workaround with the second inlet will still be necessary to get cleaner table playback at slow speeds?
thanks, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
so, here I ask, could we expect a 64 bit precision Pd for download in the next release if that PR gets in? Is it just waiting to be merged, now?
Em dom., 22 de nov. de 2020 às 19:42, Christof Ressi info@christofressi.com escreveu:
Double precision Pd indeed solves the table playback issue (among other things).
Christof
PS: "64-bit Pd" usually means Pd compiled for a 64-bit architecture, but this thread is really about double precision Pd. I'm sure you were talking about the latter, but this is a constant source of confusion, so I thought I'd better make this clear for other readers.
On 22.11.2020 23:39, Peter P. wrote:
- Dan Wilcox danomatika@gmail.com [2020-11-20 23:19]:
Note: until the sound file updates branch with the CAF file support is
merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
Dan, is this in any way related with buffer indexing? I am wondering if with 64bit Pd the B16.long-varispeed.pd workaround with the second inlet will still be necessary to get cleaner table playback at slow speeds?
thanks, P
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
It should be named dppd to avoid confusion imho.
Martin
On Sun, Nov 22, 2020 at 6:15 PM Alexandre Torres Porres porres@gmail.com wrote:
so, here I ask, could we expect a 64 bit precision Pd for download in the next release if that PR gets in? Is it just waiting to be merged, now?
Em dom., 22 de nov. de 2020 às 19:42, Christof Ressi info@christofressi.com escreveu:
Double precision Pd indeed solves the table playback issue (among other things).
Christof
PS: "64-bit Pd" usually means Pd compiled for a 64-bit architecture, but this thread is really about double precision Pd. I'm sure you were talking about the latter, but this is a constant source of confusion, so I thought I'd better make this clear for other readers.
On 22.11.2020 23:39, Peter P. wrote:
- Dan Wilcox danomatika@gmail.com [2020-11-20 23:19]:
Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
Dan, is this in any way related with buffer indexing? I am wondering if with 64bit Pd the B16.long-varispeed.pd workaround with the second inlet will still be necessary to get cleaner table playback at slow speeds?
thanks, P
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
Martin
On Sun, Nov 22, 2020 at 6:15 PM Alexandre Torres Porres porres@gmail.com wrote:
so, here I ask, could we expect a 64 bit precision Pd for download in the next release if that PR gets in? Is it just waiting to be merged, now?
Em dom., 22 de nov. de 2020 às 19:42, Christof Ressi info@christofressi.com escreveu:
Double precision Pd indeed solves the table playback issue (among other things).
Christof
PS: "64-bit Pd" usually means Pd compiled for a 64-bit architecture, but this thread is really about double precision Pd. I'm sure you were talking about the latter, but this is a constant source of confusion, so I thought I'd better make this clear for other readers.
On 22.11.2020 23:39, Peter P. wrote:
- Dan Wilcox danomatika@gmail.com [2020-11-20 23:19]:
Note: until the sound file updates branch with the CAF file support is merged, 64 bit sample indices aren't yet useful with the current core file formats (WAV, AIFF, SND) as they use 32 bit indices.
Dan, is this in any way related with buffer indexing? I am wondering if with 64bit Pd the B16.long-varispeed.pd workaround with the second inlet will still be necessary to get cleaner table playback at slow speeds?
thanks, P
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
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
Double precision Pd indeed solves the table playback issue (among other things).
Christof
PS: "64-bit Pd" usually means Pd compiled for a 64-bit architecture, but this thread is really about double precision Pd. I'm sure you were talking about the latter, but this is a constant source of confusion, so I thought I'd better make this clear for other readers.
Great clarification Christof!