I had said "*So I was thinking and then thought that the other patch was working because it wasn't a phase vocoder, so the phase alignment was not important. But now that you say this and showed your patch, I can see that you need not worry if you are using a delay. And I was actually using a delay in my non fft patch.*
*In the end my patches were different but equivalent and now I get why. It's cool to know and learn that if you are using delay you don't need to care about it.*" And I was just wrong! I wasn't using a delay line in the same way you were. I just confused. And the more I dig, the more my head hurts and the more confused I am... I guess I'm back to square one... Or worse, I guess I have more doubts now than at first :) My first surprise was to see that if you had a delread~ in a parent patch and a [vd~] into a subpatch with overlap is that it wouldn't generate discontinuities... and I'm not sure why is that... Now, you say "*Having [delwrite~] and [vd~] in the same overlapping subpatch (as you would in a spectral delay) is also not a problem. But having the [delwrite~] in the overlapping subpatch and the [vd~] outside will cause weirdness :-).*" And I tested it. And hmm, I'm not sure what you mean, cause it only works when you have a delread~ in a parent patch and a [vd~] into a subpatch with overlap. I do have spectral delay patches and they just work, but if you are listening to what comes out of both delread~ and vd~ in a subpatch, it's just bad. Check my attached patch. I don't really get why it works in the first one and it doesn't in the other two. Maybe this is a first step before venturing into the other implications of all this mess ;) cheers 2015-09-10 22:53 GMT-03:00 Christof Ressi <[email protected]>: > Thanks for testing! I was suspecting that the difference might only be a > very subtle one. But I'll check as well in next days. BTW: Your 'speed' > control looks very cool, I'm gonna try this myself. > > I think I understand your questions better now, so I'll try to give some > more concrete answers again: > > > My point was just that [vd~] acts in a special way when in an > overlapping subpatch, and that is it'll output the audio > > without discontinuities or pitch shifting because of interpreting the > overlap as oversampling. That behaviour is special > > when compared to [osc~], [phasor~] > > I don't understand what you mean here. [osc~] and [phasor~] also interpret > the overlap as oversampling, as do all objects which rely on time > information (ms, hz). In fact, overlapping is achieved by oversampling. The > reason why there won't be any discontinuities with [vd~] is because it is > only a reading object like [tabread4~] and the delay line itself is not > affected by the overlapping. You only have to be careful when dealing with > milliseconds and different sample rates. Having [delwrite~] and [vd~] in > the same overlapping subpatch (as you would in a spectral delay) is also > not a problem. But having the [delwrite~] in the overlapping subpatch and > the [vd~] outside will cause weirdness :-). > > There are actual two 'problems' with [phasor~], [osc~] and [vline~] in > overlapping subpatches: > > 1) looking from the outside they seem to run too slowly because they rely > on a higher sample rate within in the subpatch, but contrary to deliberate > upsampling, e. g. [block~ 64 1 4], the output doesn't get downsampled at > the outlets. So with overlap 4 the sample rate is 176400 Hz instead of > 44100 Hz. That means a [phasor~] with a speed of 44100 Hz has a period of 4 > samples. When it goes through the outlets it still has a period of 4 > samples but now the sample rate is 44100 Hz and its 'speed' is therefore > interpreted as only 11025 Hz. You also have to be careful with milliseconds > because they also depend on the sample rate. > (Oddly enough, [samplerate~] always outputs the global samplerate and not > the actual rate the subpatch is running at. This is why there is the > [iem_samplerate~] object in iemlib, which always gives the actual > samplerate.) > > 2) they run continously across blocks but because of overlapping they are > not phase aligned after the outlet. > > The oversampling is the only reason for all the corrections you had to do > in you patch. I attached a copy where I made some comments. I hope this > helps. If you have any more questions you can ask me. > > Cheers > > > > > > > > > > *Gesendet:* Donnerstag, 10. September 2015 um 23:00 Uhr > *Von:* "Alexandre Torres Porres" <[email protected]> > *An:* "Christof Ressi" <[email protected]> > *Cc:* Pd-List <[email protected]> > *Betreff:* Re: Re: Re: [PD] weird behavior of [vd~] in phave vocoder > (overlapping subpatches) > naaah, yeah, they're different.. oops... but doesn't really make any > difference perceptually... let me check it some more... > > 2015-09-10 17:49 GMT-03:00 Alexandre Torres Porres <[email protected]>: >> >> yeah, I have to sit again with some time and figure it out, I should do >> some tests to better understand how many objects behave. But, in the >> meantime, lets talk about something important here. >> >> > Delaying the back window [z~] is a rather lazy trick and it won't >> > give accurate results each time you change the pitch shifting >> > factor, but after one fft-window it settles. The question is if you >> > can actually here this error. When I find some time I'll make a >> > comparison between our both solutions. >> >> Are you really sure about this? Cause I've been testing it and thinking >> about it and, in my opinion, both are exactly the same thing, equally >> equivalent, and I can't hear any difference as well. >> >> Lets sort this out ;) >> >> I think that the second delay makes it a simpler patch and easier to >> understand. I'm using [cyclone/delay~] by the way, which works with samples >> - must be the same thing as [z~]. >> >> cheers >> >> 2015-09-10 14:23 GMT-03:00 Christof Ressi <[email protected]>: >>> >>> Hmmm, since we basically agree on all these things I was thinking if I >>> missed a point, because I simply don't believe that [vd~] behaves >>> differently than [tabread4~] and there is any unlogical or 'special' >>> behaviour with [vd~] within an upsampled subpatch. Maybe one thing: The >>> input of [vd~] is a time in milliseconds which is interpreted according to >>> the actual sample rate (because internally the delay lines work on samples, >>> of course). In that way it behaves like [phasor~], [vline~], [osc~]. So >>> when you send 1000 ms to a [vd~] in a subpatch with overlap 4, the delay >>> line will be read at sample 176400 (supposing the [delwrite~] is in a >>> subpatch with sample rate 44100). This is not an issue if both the >>> [delwrite~] and [vd~] are in the same subpatch. But if they are in >>> subpatches with different sample rates you have to make some adjustments. >>> If you're also aware of this behaviour than I don't know what else we >>> could've missed... >>> >>> Cheers >>> *Gesendet:* Donnerstag, 10. September 2015 um 18:10 Uhr >>> *Von:* "Alexandre Torres Porres" <[email protected]> >>> *An:* "Christof Ressi" <[email protected]> >>> *Cc:* Pd-List <[email protected]> >>> *Betreff:* Re: Re: [PD] weird behavior of [vd~] in phave vocoder >>> (overlapping subpatches) >>> yeah, it'll consider the signal input is 0 so it'll output the >>> corresponding index - which is "1" because of the interpolation. >>> >>> and yeah, I'm aware they're both buffer readers, delwrite~ / vd~ being a >>> circular / ring buffer. And my point was this difference between them, >>> where delay lines will always read/output at regular speed. >>> >>> But that is not the core of the discussion, and we actually agree on it, >>> so I'm not sure what we're talking about here. >>> >>> My point was just that [vd~] acts in a special way when in an >>> overlapping subpatch, and that is it'll output the audio without >>> discontinuities or pitch shifting because of interpreting the overlap as >>> oversampling. That behaviour is special when compared to [osc~], [phasor~] >>> and I also tried a buffer reader like [tabplay~] and got "bad" results. >>> They all don't work well in it, and so does not [vline~] by the way. There >>> might be other relevant objects to test but I'm just not thinking about it. >>> Nevertheless, I have the idea most will have problems, while some, like >>> [vd~], will be be fine. >>> >>> The thing about [tabread~] is that it solely depends on external sources >>> to read the buffers, while [vd~] doesn't, and that makes quite a practical >>> difference in my opinion. The deal with [tabread~] is that the issue is >>> more about what object is driving it and how it behaves (such as [vline~] >>> and [phasor~], which don't behave well with overlapping subpatches). >>> >>> But again, not a relevant discussion. But I do feel like making more >>> tests, I just don't know if there is a possible to test to check how the >>> behaviour or [vd~] and [tabread4~] could relate between themselves. >>> >>> > For me its sometimes a trial and error game to find all >>> > those parameters which have to be divided/multiplied >>> > by the overlap factor. But after a while of thinking >>> > everything turns out to make sense. >>> >>> yeah, it was trial and error, but I'm still not 100% sure how it makes >>> sense... hence this thread :) - but I guess I'll keep thinking more about >>> it. >>> >>> > Delaying the back window [z~] is a rather lazy trick and >>> > it won't give accurate results each time you change the >>> > pitch shifting factor, >>> >>> that's important to note, and that's why miller's patch may not have >>> been using this procedure. >>> >>> thanks >>> >>> >>> 2015-09-10 6:39 GMT-03:00 Christof Ressi <[email protected]>: >>>> >>>> "Oops, now I'm the one to say you can't compare them as equal. You >>>> see, [tabread~] needs to have an audio input to read through the array, but >>>> [vd~] is always "reading" the buffer at normal speed - so this makes them >>>> quite different. Since [tabread~] only react if some signal is feeding it, >>>> then it depends solely on that incoming signal; and thus the object who's >>>> outputting it, which could be [phasor~] or [vline~]. So it's more about >>>> which object who's driving it than itself." >>>> >>>> Again, I insist that the behaviour of [tabread4~] and [vd~] is >>>> equivalent ;-). When you don't feed any input to [tabread4~] it outputs the >>>> value at index 1. Now try to think of a delay line as simply a table which >>>> content is constantly updated at a time interval of 1/SR (SR = the actual >>>> sample rate of the subpatch containing the [delwirte~]). If you don't send >>>> any signal to [vd~], it behaves just as [tabread4~], only that the value at >>>> index 1 always changes, so it only appears that [vd~] itself is reading >>>> along a buffer. (Note that both objects can't read index 0 because of the >>>> 4-point interpolation algorithm. So with [vd~] you will never get less than >>>> a one sample delay.) >>>> To make sloppy analogy: [tabread4~] would be a band machine where the >>>> tape itself stands still why the tape head can be freely moved, whereas >>>> [vd~] would be one where the tape runs at a fixed speed and additionally >>>> the tape head can be moved too. Well, I don't know if this makes sense :-). >>>> >>>> Since you took the word "reading" in quotation marks you might be aware >>>> of all this. In that case the confusion might arise from the fact that you >>>> have to consider the relation between the 'speed' of the delay line >>>> (depending on the sample rate of the subpatch containing the [delwrite~]) >>>> and the 'speed' of the object providing the input for the [vd~]. >>>> >>>> Please anyone correct me if I'm wrong on these points! >>>> >>>> For me its sometimes a trial and error game to find all those >>>> parameters which have to be divided/multiplied by the overlap factor. But >>>> after a while of thinking everything turns out to make sense. >>>> Delaying the back window [z~] is a rather lazy trick and it won't give >>>> accurate results each time you change the pitch shifting factor, but after >>>> one fft-window it settles. The question is if you can actually here this >>>> error. When I find some time I'll make a comparison between our both >>>> solutions. >>>> >>>> Cheers, Christof >>>> >>>> >>>> >>>> >>>> *Gesendet:* Donnerstag, 10. September 2015 um 07:51 Uhr >>>> *Von:* "Alexandre Torres Porres" <[email protected]> >>>> *An:* "Christof Ressi" <[email protected]> >>>> *Cc:* Pd-List <[email protected]>, "Gerd Schuller" < >>>> [email protected]> >>>> *Betreff:* Re: [PD] weird behavior of [vd~] in phave vocoder >>>> (overlapping subpatches) >>>> >>> unlike [osc~], [vd~] will get the continuities between blocks >>>> right!" >>>> >>>> > You can't really compare these two objects. >>>> >>>> Sure I can :) i'll insist on it by the way. Again, [vd~] will not >>>> generate discontinuities with the overlaps, unlike other objects such as >>>> [osc~] and [phasor~]. Moreover, and as a logical result, it won't change >>>> the pitch because of the oversampling. It'll just work fine. >>>> >>>> > [vd~] is actually the same thing as [tabread4~] >>>> >>>> Oops, now I'm the one to say you can't compare them as equal. You see, >>>> [tabread~] needs to have an audio input to read through the array, but >>>> [vd~] is always "reading" the buffer at normal speed - so this makes them >>>> quite different. Since [tabread~] only react if some signal is feeding it, >>>> then it depends solely on that incoming signal; and thus the object who's >>>> outputting it, which could be [phasor~] or [vline~]. So it's more about >>>> which object who's driving it than itself. >>>> >>>> When it comes to [vd~], the pithc shifting and time stretching also >>>> depends on the object that's driving the input, which could be again >>>> [phasor~] or [vline~] and need to deal with their behaviour. >>>> >>>> > you have to divide by the overlap factor, because then >>>> > you read less samples and therefore virtually slow the >>>> > [vline~] down. In a subpatch with overlap 4 everything >>>> > happens 4 times as fast because instead of only 1 block >>>> >>>> yeah, sure, I've pointed it in my 1st message. I get that. >>>> >>>> But as I asked, I don't really get how ALL parameters need to divided >>>> by 4, not only the [vline~] time, that is not clear yet. Sorry. >>>> >>>> And by the way, my patch does also time stretching, so it's different >>>> than yours and is dealing with more parameters and issues than you. So you >>>> are addressing the [vline~] issue only (replaced by [phasor~] in your >>>> patch) - but that was the only parameter that I really understood anyway. >>>> >>>> > When using [z~] to delay the back window simply by the >>>> > fft hop size you don't have to care about window sizes >>>> >>>> hmm, my problem was more why were my two patches different, the one >>>> with fft needed to care about it, but the other one didn't. I actually get >>>> why that thing needs to be done to properly phase align the windows. >>>> >>>> So I was thinking and then thought that the other patch was working >>>> because it wasn't a phase vocoder, so the phase alignment was not >>>> important. But now that you say this and showed your patch, I can see that >>>> you need not worry if you are using a delay. And I was actually using a >>>> delay in my non fft patch. >>>> >>>> In the end my patches were different but equivalent and now I get why. >>>> It's cool to know and learn that if you are using delay you don't need to >>>> care about it. >>>> >>>> thanks >>>> >>>> ps. I'm still curious on sorting out the behaviour of [vd~] though >>>> >>>> >>>> >>>> 2015-09-09 7:54 GMT-03:00 Christof Ressi <[email protected]>: >>>>> >>>>> Hi Alexandre, >>>>> >>>>> I'm new on this list, but I think I can help you on this because >>>>> recently I tried to do the same thing. I can't fully test your patch >>>>> because I'm missing the cyclone library (and don't bother to install it >>>>> :-p). I try to give an answer to the following questions: >>>>> >>>>> "Other issues related to overlapping besides this "oversampling" is >>>>> that some objects won't make it right, they'll chop the blocks with >>>>> discontinuities, such as the case with [osc~]. But as it turns out, unlike >>>>> [osc~], [vd~] will get the continuities between blocks right!" >>>>> >>>>> You can't really compare these two objects. [vd~] is actually the same >>>>> thing as [tabread4~], only that it reads from a ring buffer rather from a >>>>> table. So the critical thing is only which object you use as the input for >>>>> [vd~]. You are using [vline~] whereas I'm using [phasor~]. Both are >>>>> equivalent. For the reading index for [vd~] you have to divide by the >>>>> overlap factor, because then you read less samples and therefore virtually >>>>> slow the [vline~] down. In a subpatch with overlap 4 everything happens 4 >>>>> times as fast because instead of only 1 block, 4 blocks have to be >>>>> processed - in the same time!). My approach is to have a [phasor~] run >>>>> from >>>>> 0 to 1 (or 1 to 0) for every block so I have to multiply it's speed by >>>>> four. Than I multiply the output by the windows size. Note that in my >>>>> patch >>>>> I get the second window one hop size behind by simply delaying it with >>>>> [z~] >>>>> whereas you've chosen to use a second [vd~] with a wrapping object. (I >>>>> guess you're way actually saves some memory as you don't need a second >>>>> delay line). >>>>> >>>>> "And even more weirdly, in the Pvoc patch I have to multiply the >>>>> difference between the front and back windows to the ratio of >>>>> transposition. This is even crazier than the last issue, and I have no >>>>> idea >>>>> why that has to be this way..." >>>>> >>>>> When you're transposing you're actually reading more samples for >>>>> upwards pitchshifting and less samples for downwards pitchshifting. So you >>>>> basically stretch or compress the window size. This means also that the >>>>> time difference between two windows changes if you want them to be phase >>>>> aligned. If the window gets larger, the time difference to the last window >>>>> also gets larger and vice verca. You might be aware of this: The window in >>>>> the back has to be phase aligned with the front window because you need it >>>>> as a reference to calculate the difference from the actual phase of the >>>>> previous output window. >>>>> >>>>> When using [z~] to delay the back window simply by the fft hop size >>>>> you don't have to care about window sizes and time differences at all. It >>>>> is, however, also a bit incorrect for the first analysis window after a >>>>> change of pitch so I might change it and try it your way! >>>>> >>>>> You can have a look at my solution and compare it to yours. From what >>>>> I've seen both work the same way though I couldn't test your patch. >>>>> However, I think that my patch could be conceptually easier to understand, >>>>> but I might be wrong :-). >>>>> >>>>> Cheers, Christof >>>>> >>>>> PS: Ignore the right half of [pd read-windows] with the two >>>>> [tabread4~], this is only needed for the freeze effect. >>>>> >>>>
good-bad_delay-tests.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
