I so wish these double precision float patches could be rolled into the main branch.
This issue of indexing into long arrays is the biggest thing impacting my PD joy I've found.
Unless I'm missing something, the onset inlet to [tabread4~] is not an acceptable solution, since it is only *added* to the value (address) on the left inlet. So instead of first encountering noise at 150,000 bytes into the array, we defer the problem to 300,000? This is just 7 seconds @ 44.1khz, and I want to work with audio files potentially 2 hrs long.
Thanks Katja for your work on this.
On Tuesday, June 2, 2015, Arshia Cont Arshia.Cont@ircam.fr wrote:
Thank you Katja for the swift response! We will wait for that then.
Any one running into run-time problems when compiling with C++11 or
C++14? We seem to have memory alignment issues… .
Arshia Cont
On 02 Jun 2015, at 14:23, katja katjavetter@gmail.com wrote:
On Tue, Jun 2, 2015 at 1:07 PM, Arshia Cont Arshia.Cont@ircam.fr wrote:
[...]
My second question would be on double-precision audio externals.. I see
discussions on class_new64 but can’t seem to find any trace of it in 0.46-6.. I dig into the archives to figure this one out first!
In 2011 I made a set of patch files for vanilla pd 0.43 to enable double precision builds (where t_float and t_sample are doubles). That can be found here:
https://github.com/pd-projects/pd-double
You could try it out for evaluation but Miller wants to scrutinize, test and improve the patch files before accepting them.
Katja
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev