reblocking to a *lower* blocksize doesn't make a delay. but why don't you use a 
delay line ;-)? for a 1 sample delay you can also do [rzero_rev~ 0] or - if you 
use zexy - [z~ 1].
 
regarding [sigmund~]: since the object uses FFT inside, it just collects enough 
samples for the given window size (default 1024) and doesn't really care about 
the actual blocksize of the patch it sits in. but note that a lower blocksize 
creates higher CPU usage.

why do you want to delay the signal by one sample before going into sigmund~ in 
the first place?

Gesendet: Sonntag, 16. Oktober 2016 um 07:02 Uhr
Von: "Fede Camara Halac" <camaraf...@gmail.com>
An: pd-list@lists.iem.at
Betreff: [PD] Sigmund+reblocking

Hi all,
 
Would reblocking a subpatch have any effect on [sigmund~]? 
 
Below is what I did. My idea was to delay the signal by one sample before going 
to sigmund. This is certainly not what is happening, though, but sigmund still 
works for all 10 tracks as if no reblocking had been made. Is sigmund 
overriding the block object and reblocking to 128?
 
[block~ 1]
 
[inlet~]
|
[sigmund~ -hop 1024 -npeak 10 tracks]
|
 
[outlet~]
 
 
Thanks!
 
Fede
 
fedecamarahalac.com[http://fedecamarahalac.com]

 _______________________________________________ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to