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.*)
Christof
*) 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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list@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