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" <>
> An: "Christof Ressi" <>
> Cc:
> 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

_______________________________________________ mailing list
UNSUBSCRIBE and account-management ->

Reply via email to