Hi João,
if you need to be sample precise and use pd vanilla, I'd recommend to define custom tabread~/tabwrite~ abstractions using multiple arrays for access (similar to an old memory mapping technique called "paging").
You'd have to define a custom number format using a list of two numbers in the range [0..2^24] to specify a precise sample offset. In addition you'd need a custom tabread~ and tabwrite~ abstraction, abstracting the paging so they can be used the same way as the builtin objects (albeit with the sample idx being the two number lists). As tabwrite~ accepts a table offset you'd have the same functionality as the builtin objects.
I did this some years ago and it worked pretty well. The only disadvantage is that saving such a multi-array buffer will result in multiple files, but this probably is of minor concern as you can combine them into a single buffer when this is needed in an external app.
-- Orm
Am Sonntag, den 02. Dezember 2018 um 14:22:35 Uhr (+0100) schrieb João Pais:
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