[PD] tabwrite onset
christof.ressi at gmx.at
Sun Dec 2 15:00:21 CET 2018
> 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.
> Gesendet: Sonntag, 02. Dezember 2018 um 14:22 Uhr
> Von: "João Pais" <jmmmpais at gmail.com>
> An: PD-List <pd-list at 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.
> 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