[Csnd] Sliding phase vocoder and overlap
| Date | 2013-09-03 21:00 |
| From | Andres Cabrera |
| Subject | [Csnd] Sliding phase vocoder and overlap |
Hi, I've been trying to use the sliding phase vocoder and it seems to me that the naming of the parameters for pvsanal are misleading as ioverlap should be called ihop, as a value of 1 should be used for sliding phase vocoder. Is that correct?Cheers, Andres |
| Date | 2013-09-03 21:46 |
| From | Richard Dobson |
| Subject | Re: [Csnd] Sliding phase vocoder and overlap |
Ah, vocabulary! "ihop" is reasonable enough for pvoc; the "conventional" phase phase vocoder is often referred to, especially in more recent papers, as the hopping phase vocoder specifically to distinguish it from the one-sample sliding form. On the other hand, "sliding" is also widely used (arguably, incorrectly) to describe the conventional hopping phase vocoder, as also a number of other related algorithms which use overlapping windows. The term sliding in this context refers indirectly to the underlying "sliding dft" (pretty well-established as a dsp technique now) on which it is based. I have no particular problem with referring to "a single-sample overlap"; the sliding pvoc is in effect a special case of the general hopping vocoder using an overlap (if we may still call it that) of one sample, which enables a particularly simple and efficient implementation. Arguably "hop" would be more confusing when applied to the sliding pvoc as the single-sample update is surely not a hop; more of a step. Historically, the word "overlap" is by far the most common term in the context of the general phase vocoder, and reasonably describes the sliding form too. It is no different semantically from having "ksmps = 1" and still refer to a control rate. Maybe we should refer to "hopping" and "stepping" phase vocoders? But having two names for one parameter in one opcode will probably be just as confusing as sticking with one name! Richard Dobson On 03/09/2013 21:00, Andres Cabrera wrote: > Hi, > > I've been trying to use the sliding phase vocoder and it seems to me > that the naming of the parameters for pvsanal are misleading as ioverlap > should be called ihop, as a value of 1 should be used for sliding phase > vocoder. Is that correct? > > Cheers, > Andres |
| Date | 2013-09-03 21:53 |
| From | Andres Cabrera |
| Subject | Re: [Csnd] Sliding phase vocoder and overlap |
Hi, Thanks for the ideas, but I mean that if it was called ioverlap, I would expect to use the sliding phase vocoder like this (I actually tried this, and was baffled as to why it didn't work...):fsig pvsanal a1,1024,1,1024,1 Andrés On Tue, Sep 3, 2013 at 1:46 PM, Richard Dobson <richarddobson@blueyonder.co.uk> wrote: Ah, vocabulary! "ihop" is reasonable enough for pvoc; the "conventional" phase phase vocoder is often referred to, especially in more recent papers, as the hopping phase vocoder specifically to distinguish it from the one-sample sliding form. On the other hand, "sliding" is also widely used (arguably, incorrectly) to describe the conventional hopping phase vocoder, as also a number of other related algorithms which use overlapping windows. The term sliding in this context refers indirectly to the underlying "sliding dft" (pretty well-established as a dsp technique now) on which it is based. I have no particular problem with referring to "a single-sample overlap"; the sliding pvoc is in effect a special case of the general hopping vocoder using an overlap (if we may still call it that) of one sample, which enables a particularly simple and efficient implementation. Arguably "hop" would be more confusing when applied to the sliding pvoc as the single-sample update is surely not a hop; more of a step. |
| Date | 2013-09-03 22:03 |
| From | Richard Dobson |
| Subject | Re: [Csnd] Sliding phase vocoder and overlap |
Overlap is used in the sense of "degree of temporal separation". It is the inverse of the analysis frame rate. A "half-window" overlap is the maximum separation viable given the use of symmetrical analysis windows sucm as Hann (some windows require a minimum 25% overlap, etc); that would be e.g. 1024, 512, 1024. Or, if you like, how much of a frame is left exposed by the next one. There is nothing wrong semantically with what you propose, it is just that the established meaning of the analysis frame overlap is as above; so that to activate the sliding pvoc you do need to specify 1 (or a v low number) for the overlap. That's just the way it has turned out, with the sliding pvoc facility added to the existing opcode and framework in which all the parameter names have a history of several decades of established use behind them. Richard Dobson On 03/09/2013 21:53, Andres Cabrera wrote: > Hi, > > Thanks for the ideas, but I mean that if it was called ioverlap, I would > expect to use the sliding phase vocoder like this (I actually tried > this, and was baffled as to why it didn't work...): > > fsig pvsanal a1,1024,1023,1024,1 > > Because 1023 samples overlap, where as if it was called hop there is a > one sample "hop": > > fsig pvsanal a1,1024,1,1024,1 > > Does this makes sense? > |
| Date | 2013-09-03 22:17 |
| From | Andres Cabrera |
| Subject | Re: [Csnd] Sliding phase vocoder and overlap |
Hi Richard, Thanks for the explanation, makes sense now.Andrés On Tue, Sep 3, 2013 at 2:03 PM, Richard Dobson <richarddobson@blueyonder.co.uk> wrote: Overlap is used in the sense of "degree of temporal separation". It is the inverse of the analysis frame rate. A "half-window" overlap is the maximum separation viable given the use of symmetrical analysis windows sucm as Hann (some windows require a minimum 25% overlap, etc); that would be e.g. 1024, 512, 1024. Or, if you like, how much of a frame is left exposed by the next one. There is nothing wrong semantically with what you propose, it is just that the established meaning of the analysis frame overlap is as above; so that to activate the sliding pvoc you do need to specify 1 (or a v low number) for the overlap. That's just the way it has turned out, with the sliding pvoc facility added to the existing opcode and framework in which all the parameter names have a history of several decades of established use behind them. |