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 <[email protected]>: > 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 <[email protected]>: > >> 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 <[email protected]>: >> >>> > 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 <[email protected]>: >>> >>>> > 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" <[email protected]> >>>> *An:* "Christof Ressi" <[email protected]> >>>> *Cc:* Pd-List <[email protected]> >>>> *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 <[email protected]>: >>>>> >>>>> 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 <[email protected]>: >>>>>> >>>>>> 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: >>>>>> >>>>>> 1) 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. >>>>>> >>>>>> 2) 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. >>>>>> >>>>>> 3) 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" <[email protected]> >>>>>> *An:* "Christof Ressi" <[email protected]> >>>>>> *Cc:* Pd-List <[email protected]> >>>>>> *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 <[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. >>>>>>>>>>> >>>>>>>>>> >>> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
