[PD] sampstoms~ (was Re: weird behavior of [vd~] in phave vocoder (overlapping subpatches))

[Alexandre Torres Porres]

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 at 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 at 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 at 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 at 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 at gmail.com>
>>>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>>>> *Cc:* Pd-List <pd-list at 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 at 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 at 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:
>>>>>>
>>>>>> 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" <porres at gmail.com>
>>>>>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>>>>>> *Cc:* Pd-List <pd-list at 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 at 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 at gmail.com>
>>>>>>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>>>>>>> *Cc:* Pd-List <pd-list at 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 at 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 at 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 at gmail.com>
>>>>>>>>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>>>>>>>>> *Cc:* Pd-List <pd-list at 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 at 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 at gmail.com>
>>>>>>>>>> *An:* "Christof Ressi" <christof.ressi at gmx.at>
>>>>>>>>>> *Cc:* Pd-List <pd-list at lists.iem.at>, "Gerd Schuller" <
>>>>>>>>>> studio at 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150927/349c5323/attachment-0001.html>