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 >
--
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)