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. >>>> >>> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
