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>
Betreff: [PD] Sigmund+reblocking
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?
[sigmund~ -hop 1024 -npeak 10 tracks]
_______________________________________________ Pdemail@example.com mailing
list UNSUBSCRIBE and account-management ->
Pdfirstname.lastname@example.org mailing list
UNSUBSCRIBE and account-management ->