[PD] tabwrite onset
Christof Ressi
christof.ressi at gmx.at
Sun Dec 2 15:12:59 CET 2018
if you need to be really sample accurate, checkout https://git.iem.at/pd/iem_dp. it provides several table objects with an additional onset inlet.
> Gesendet: Sonntag, 02. Dezember 2018 um 15:00 Uhr
> Von: "Christof Ressi" <christof.ressi at gmx.at>
> An: "João Pais" <jmmmpais at gmail.com>
> Cc: PD-List <pd-list at lists.iem.at>
> Betreff: Re: [PD] tabwrite onset
>
> > 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 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.
> >
> > Best,
> >
> > Joao
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> >
>
>
>
> _______________________________________________
> 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