[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