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
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@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%5Bhttps://lists.puredata.info/l...]
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
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
-
Christof Ressi -
Fede Camara Halac