[PD] tabwrite onset

[Christof Ressi]

> 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
>