[PD] tabwrite onset

Orm Finnendahl orm.finnendahl at selma.hfmdk-frankfurt.de
Sun Dec 2 15:52:52 CET 2018


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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list