how, both [cyclone/sampstoms~] and [cyclone/mstosamps~] will convert number input only to number outlet. I thought this didn't make sense, and in fact in Max it also converts to signal output. It makes sense though that audio input only converts to signal output.
cheers
2015-09-19 19:55 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
in max, these objects won't convert differently in overlapping subpatches for fft, so it's a global pd thing, it'll interfere in the way many objects work, like vline~ / phasor~ / whatever... sampstoms~ is just another one, but it may be come in hand to deal with wrong time computations.
anyway, maybe leave it as it is, or maybe a mention in the help file would be nice.
cheers
2015-09-12 20:32 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
one thing related to what was discussed on that thread.
[cyclone/sampstoms~] and [cyclone/mstosamps~] will convert between ms and samples account for the oversampling of the overlaps in block
so it'll consider [block~ 2048 4] to have 4x the sample rate of what pd is running.
This actually works great if you want to use that to feed ms to [vd~] and [vline~], which need to be corrected for that matter. I still think [vline~], [vd~], [phasor~] and all could behave in a way that they didn't need to be corrected... but... whatever, at least documenting this is important.
equally, it'd be nice to either change or document [cyclone/sampstoms~] and [cyclone/mstosamps~] (a minor mention or demo in the help file should do it).
Do you get this Fred? Need me to help you with that? Here's a patch attached.
cheers
2015-09-12 20:22 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
But [vd~] itself does nothing regarding to overlap and that's very important to understand. It just behaves like [tabread4~].
I still like considering vd~ special, but I totally see and understand what you mean ;)
I think this is just an issue of proper documentation!
Agreed, we should ask miller to document this somewhere ;)
Have you tried listening to the difference by listening to the delay lines?
I was testing something about these delays and I'm actually getting some parallel issues, I might and should open a new thread to discuss them.
One last thing from the original post,. We've sorted the delay times and everything, but I was also asking why we have to multiply for the interval ratio to get the hop difference between the two windows in the phase vocoder.
In fact, I actually know why, and the question needs to be rephrased. The proper question would have been why it DOESN'T have to multiply by the ratio in the other patch that wasn't a phase vocoder (if you go back to my very first attachment you'll see I had two patches and I was comparing them, this was one of the issues).
And you "didn't have to" multiply it because it was working fine... But the truth is that it works better if you multiply it by the ratio, and it just can go unnoticed because it's not a phase vocoder, so it doesn't ruin things as is the case with the phase vocoder.
Isn't it great to have it all sorted?
Thanks for your great help
ps. I noticed your last reply was off the list, so I got us back to settle and close the thread.
2015-09-12 6:23 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
But the point is, [tabread4~] won't automatically do anything, unlike
[vd~]. At least that is how I see it.
Hmmm... maybe you might have to go back to my explanation of point 1) and see how the overlapping only works fine all the time because the state of the delay line outside the subpatches happens to change synchroniously with the time the input buffer is taken for one of the overlapping windows. Window2 will get the input buffer one hope size time later than window1, and in that same time the delay line itself has moved for the same amount of samples. So after overlapping again at the output, everything is fine again. But [vd~] itself does nothing regarding to overlap and that's very important to understand. It just behaves like [tabread4~].
You're last patch shows that you fully understand how oscillators and ramps work in overlapping subpatches. I've attached a patch where you can have a look how a delay line actually looks like inside such a subpatch. You can also see that a samplewise delay like [z~] (or [delay~]) is equivalent to a sorted pair of [delwrite~] and [delread~] and acts the same way. I've exchanged [vd~] for [delread~] to get rid of the problem with index 0.
or, in the meantime, can you explain why using a delay~ line is
different as you understand it? I mean, what problems does it generate and all?
So you from checking my patch you can see that they actually behave the same way! In the case of my [cpitchshift~] patch, the difference arises from the fact, that the [vd~] acts on a delay line outside the subpatch where [z~] is a delay line which is fully located inside the subpatch. Note that the delay time in samples is 1/4 window size, so it's 1 hop size and doesn't create discontiuities. It is just a lazy way to guarantee that the back window is 1 hop size behind :-). The problem only is: When you change the pitch at a certain point of time, the buffer of [z~] has been filled at a time where that pitch change has not occured yet. But after one window calculation it's fine again (unless you've again changed the pitch and so on...).
But then, I kinda think this is a bug! Not only a [vd~] bug, but also
[vline~] and [phasor~] / [osc~] (regarding frequency).
Well, the oversampling is happening, if you want it or not :-). And I think 1 second always should have as many samples as the sampling rate. I guess most of the misunderstandings come from the fact that the oversampling itself is not documented properly... and that [samplerate~] behaves unlogically! The phase correction for oscillators and ramps could be done internally in the objects, but then this might lead to other weird behaviour instead so it's kind of a trade off. Again, I think this is just an issue of proper documentation!
Cheers
*Gesendet:* Freitag, 11. September 2015 um 20:55 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* Pd-List pd-list@lists.iem.at *Betreff:* Re: Re: Re: Re: Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches) "*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...*"
Yeah, I wasn't really aware of this, and it seems to settle the whole doubt about why do we have to divide all time values by the overlap with [vd~].
I surely had an idea that it made sense, but not exactly why, and now that you've explained how time in ms is converted internally to sample number it makes sense.
But then, I kinda think this is a bug! Not only a [vd~] bug, but also [vline~] and [phasor~] / [osc~] (regarding frequency).
I still need to come back about the need to multiply for the window size in order to back down an overlap, and wether using delay~ lines instead of that is the exact same thing or wether is just not perceptually different... just wait...
or, in the meantime, can you explain why using a delay~ line is different as you understand it? I mean, what problems does it generate and all?
thanks
2015-09-11 15:38 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Thanks for the detailed explanation. It was very clear. A couple of other remarks, in 1) and 2) you have an output that is 4 times greater because they add up. If I'd used delread~ in 2) I'd have thought it was ok :) - it was weird to me why it wasn't working but now I get it.
I had an idea why 1) worked, as I was saying from the beginning and we know well, it does the overlapping fine without discontinuities. So I was saying it dealt fine with overlapping, we can say it does it "automatically".
Now, back to my saying how [vd~] and [tabread4~] behave differently. Attached I have an oscillator that was recorded into a buffer/array. Then I'm reading it from overlapping subpatches. So, now, there are discontinuities. They don't work the same way, and that was my point.
I'm reading it with [tabplay~] and [tabread4~] driven by [vline~] (which has to be 4x faster for it to work).
But then, as we also know, the deal is how [vline~] drives it. It'll generate a line without discontinuities and on the way out they'll be overlaped and added, and this ruins things. Same happens automatically in [tabplay~], no need for vline~ to ruin it.
On the other hand, we can force [vline~] to overlap and make it alright.
But the point is, [tabread4~] won't automatically do anything, unlike [vd~]. At least that is how I see it.
But again, that is not what's most important about sorting out my patch, and now that this seems fine, I should get back to trying to sort that from the beginning all over again. Hopefully with more idea of what's going on.
cheers
2015-09-11 7:18 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Luckily I can offer you (hopefully) clear explanations for all three cases :-). Here we go:
First some background information: In an subpatch with overlap 4, the input and output buffers are overlapping, but internally the calculation of the 4 windows happens sequentially. This is why a [phasor~] from a parent patch will pass the subpatch unchanged (only the amplitude is four times because of the summing), while a [phasor~] inside will look messed up after the outlet. Ok, I know you know all this. But all this also applies to delay lines. Now let's examine the three cases:
- the [delwrite~] is in the parent patch. Let's suppose we have a
blocksize of 8 and overlap 4 (thus hopsize of 2). Because the [delwrite~] is in the parent patch, it is just treated the same way as something coming from the inlet. [vd~] reads the index 1 of the ringbuffer at the following points of time:
window 1: ----- 0 1 2 3 4 5 6 7 window 2: ----- 2 3 4 5 6 7 8 9 window 3: ----- 4 5 6 7 8 9 10 11 window 4: ----- 6 7 8 9 10 11 12 13
Window2 reads 2 samples later than window1, window3 reads 2 samples later than window2 and so on... If you overlap and sum it at the outlets, you end up with everything aligned in the right way. This is exactly the reason why you don't get any discontinuties.
- both the [delwrite~] and [vd~] are in the subpatch. The delay line
inside the subpatch is written the following way:
0 1 2 3 4 5 6 7 (,) 2 3 4 5 6 7 8 9 (,) 4 5 6 7 8 9 10 11 (,) 6 7 8 9 10 11 12 13 (,) 8 9 10 11 12 13 14 15 etc... where the numbers again represent points of time in the input buffer.
So the 4 windows are written sequentially into the delay line, because internally window calculation happens sequentially (as I've mentioned above). So there are indeed discontinuities which you have to take care of. Now suppose you reed the delay line at index 0 for each window: Because the delay line is constantly running, window 1 might start from 0, window 2 then starts from 2 (because it's calculated after window1, so in the meantime the ring buffer has moved by 8 samples), window3 from 4, window4 from 6 etc... If you do the overlap, the delay line is again preserved. But what if you don't read at the ring buffer at index 0 for all windows? Suppose [vd~] reads from index 7, than the output for window1 would be 6 7 2 3 4 5 6 7, window2 would be 8 9 4 5 6 7 8 9, so the output is messed up! Now if you think of it, the condition for preserving the delay line is setting the index of [vd~] to a multiple of the hop size. Only then each window will read a sequence from the buffer that is continious. But wait, why didn't it work for you? It's just because in your patch [vd~] was set to 0, but it can't read from index 0, instead it will read from index 1, which screws everything up because it's not a multiple of the hop size. I added sum message boxes where you can try out some good and some bad numbers. BTW: this behaviour of [delwrite~] inside an overlapping subpatch is also the reason why you have to multiply the maximum buffer size by the overlap factor, because it needs four times as much samples. Additionally this explains why for a spectral delay, the delay time must be a multiple of the window size time and not the hop size time, because only that way continuity is garanteed.
- This is just as messed up as I predicted, because you're simply
'reading along' the 'weird' delay line above. :-)
Don't worry, it took me some time to figure this all out, because this is nowhere documented explicitly, it just follows implicitely from the behaviour of overlapping subpatches (which is also not documented properly at all... the oversampling and sequential calculation should be mentioned in the helpfile of [block~] at least --> possible bug fix?)
Tell me if that makes sense to you. When I find some time I could make a nice graphic visualizing these issues in a better way.
Cheers
*Gesendet:* Freitag, 11. September 2015 um 08:06 Uhr *Von:* "Alexandre Torres Porres" porres@gmail.com *An:* "Christof Ressi" christof.ressi@gmx.at *Cc:* Pd-List pd-list@lists.iem.at *Betreff:* Re: Re: Re: Re: [PD] weird behavior of [vd~] in phave vocoder (overlapping subpatches) 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 christof.ressi@gmx.at: > > 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" porres@gmail.com > *An:* "Christof Ressi" christof.ressi@gmx.at > *Cc:* Pd-List pd-list@lists.iem.at > *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 <porres@gmail.com > >: >> >> 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 christof.ressi@gmx.at: >>> >>> 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" porres@gmail.com >>> *An:* "Christof Ressi" christof.ressi@gmx.at >>> *Cc:* Pd-List pd-list@lists.iem.at >>> *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 christof.ressi@gmx.at: >>>> >>>> "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" porres@gmail.com >>>> *An:* "Christof Ressi" christof.ressi@gmx.at >>>> *Cc:* Pd-List pd-list@lists.iem.at, "Gerd Schuller" < >>>> studio@gerdschuller.com> >>>> *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 christof.ressi@gmx.at: >>>> >>>>> >>>>> 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. >>>>> >>>>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list