[PD] Sigmund+reblocking

Christof Ressi christof.ressi at gmx.at
Sun Oct 16 16:23:45 CEST 2016

you're welcome! 

> Do you mean lower than 64?
Generally. The idea about calculating audio samples in blocks is that you only have to call the dsp perform routines every N samples. The lower the block size, the more often the routine gets called, thus CPU usage rises.

Sometimes you want to increase the blocksize above 64 for mere effiency reasons (in opposition to, say, FFT subpatches where it is often needed). An example for this is upsampling:
You could do [block~ 64 0 4] (upsampling by a factor of 4), but it's generally a good idea to increase the blocksize accordingly - in this case [block~ 256 0 4] - to save some CPU load.*) 


*) Also, some objects like [block~] or [vline~] don't work correctly below the rate of Pd's scheduler - which is 64 samples @ 44100 Hz or 128 samples @ 88200 Hz and so on. Another reason to increase the blocksize for upsampling.

> Gesendet: Sonntag, 16. Oktober 2016 um 15:32 Uhr
> Von: "Fede Camara Halac" <camarafede at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: pd-list at lists.iem.at
> Betreff: Re: Aw: [PD] Sigmund+reblocking
> Hi Christof,
> Thanks for this
> >  for a 1 sample delay you can also do [rzero_rev~ 0] or - if you use zexy - [z~ 1].
> I suspected this about sigmund but I was not sure
> > doesn't really care about the actual blocksize of the patch it sits in.
> About blocksize and CPU:
> > but note that a lower blocksize creates higher CPU usage.
> Do you mean lower than 64?
> > why do you want to delay the signal by one sample before going into sigmund~ in the first place?
> there had to be 1 samp delay between the index of tabread4 and the analysis of its output. I'm thinking now in other ways of doing this!
> Again, this was just my idea and I guess overnight patching does strange things to you. 
> Thanks again!
> Fede
> fedecamarahalac.com

More information about the Pd-list mailing list