hi
attached is a demo-patch, that shows the fact, that the delaytime of [vd~] or [delread~] has to be divided by the overlap factor, if the [vd~] is in a subpatch with an overlap factor > 1. when building the fft-pitchshifter, i spent a lot of time finding out about that. thinking about that, it is getting more and more clearer, but i'm still unsure if i understand right, how overlapping in subpatches works. just a few assumptions:
- setting an overlap factor n is like upsampling, so that the samplerate
inside the subpatch is the main samplerate multiplied with n ? (that would explain the issue with [vd~])
- each vector takes the n-th part of computation time, compared to normal
computation time of a vector?
- the n vectors in a cycle are computed sequentially?
- the [outlet~]-object outputs the average vector of all n vectors in one
cycle, so that the output has the main samplerate again?
is there a good docu about handling of overlapping in pd?
cheers
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
This is a bug... I've never figured out the correct way to handle delay lines across reblocking boundaries. I should put a mention of that on the help window...
M
On Mon, Mar 13, 2006 at 02:30:22PM +0100, Roman Haefeli wrote:
i forgot the attachment....
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I noticed something odd when I placed a z~ object inside a block with overlap factor two.... When the signal comes through, there is a place in each block where the boundary comes in, and the signal gets "chopped up" half of it in one block, and half in the next block.
Chuck
On 3/13/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
This is a bug... I've never figured out the correct way to handle delay lines across reblocking boundaries. I should put a mention of that on the help window...
M
On Mon, Mar 13, 2006 at 02:30:22PM +0100, Roman Haefeli wrote:
i forgot the attachment....
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Charles Zachary Henry
anti.dazed.med Med student who needs a Mickey's
hi chuck
"Charles Henry" czhenry@gmail.com wrote:
I noticed something odd when I placed a z~ object inside a block with overlap factor two.... When the signal comes through, there is a place in each block where the boundary comes in, and the signal gets "chopped up" half of it in one block, and half in the next block.
it should be normal, since pd computes signals as vectors of a given size. independently from the overlap factor, a vector gets splitted up, if you delay it (of course not with a delay time, that is a multiple of the block-size). i attached a patch, that demonstrates, that [z~] works as expected, also in subpatches with an overlap factor > 1.
cheers
roman
-
Charles Henry -
Miller Puckette -
Roman Haefeli