[PD] Sigmund+reblocking

[Christof Ressi]

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" <camarafede at gmail.com>
An: pd-list at 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 at lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]