Since this patch uses extended objects, I can't use Pd64b.
64-bit is only about pointer size, *not* about double precision.
the problem with using floats for large array indices is that after a certain size you gradually loose precision in the lower bits. in your case you could use [array set] and [array get] to read/write several samples at once. this way you don't have to give precise indices for every sample but only an onset plus a size. the onset value will not be precise (a few samples off depending on the size) but the actual samples will be written consecutively and thus won't degrade in quality.
Christof
Gesendet: Sonntag, 02. Dezember 2018 um 14:22 Uhr Von: "João Pais" jmmmpais@gmail.com An: PD-List pd-list@lists.iem.at Betreff: [PD] tabwrite onset
Hello list,
I'm creating long tables (+20m, @22.05KHz, Pd 32b windows), where I read a
short voice sample from another table and copy them into different places
in the long table. Since that's running outside of the audio chain, I'm
using [tabread]+[tabwrite]. The idea is to generate an audio file from a
list of events without having to "bounce" the playback.I notice that the further away the samples are copied to, the worse the
audio quality gets. There is an onset parameter for [tabread4~] to help in
these cases, but not any for [tabwrite]. Do you advise any solutions to
this? I could split the long buffer in several buffers, but at some point
it would have to be put together. Or maybe a clever use of [block~] to
make a subpatch that would go very fast through the table?Since this patch uses extended objects, I can't use Pd64b. I would prefer
to use vanilla objects for this module, if possible.Best,
Joao
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list