Am 01.06.2014 19:37, schrieb hermann meyer: Some more information here: http://www.linuxmusicians.com/viewtopic.php?f=48&t=12300&start=15#p…

Okay, so top posting is requested here? Yea, that's what it does actual. you can *adds* a octave up/down with GxDetune. You can mixed dry / wet. (seperate controllers for dry and wet signal from 0 - 100 % for each). You can delay the added octave for the latency, or you can compensate it internal, so that dry and wet signal comes in sync. screenshot: http://oi62.tinypic.com/34njmo3.jpg Am 01.06.2014 20:14, schrieb rosea grammostola:

On 02/06/14 15:04, rosea grammostola wrote: Options -> Show Values rob

Must be said, I've a lot of fun using this plugin (in Carla git version), thanks! On Fri, Jun 6, 2014 at 12:43 PM, hermann meyer <brummer-(a)web.de> wrote:

On Sat, Jun 07, 2014 at 10:15:41AM +0200, hermann meyer wrote: This sort of works, but it's not what it claims to be. The whole part that finds the exact frequency by comparing phases is completely redundant. This information is never really used. It just looks as if it is used. For example, for one octave up, you could just as well take the magnitude and phase of bin k, multiply the phase by 2 and put the result in the input bin 2*k of the inverse FFT. The result would be just the same. No frequency calculation is ever made. The net result is also equivalent to: - overlap - windowing (as in your code) but then: - downsample by 2 - repeat the result so you get the original length - add to output Which doesn't even require an FFT. The way to really use the computed frequencies would be quite different. If you have a signal at some frequency F there will be significant energy in a number of bins close to F. The correct value of F can be found by comparing the phases as explained by Bernsee. Given this F you need some way to determine which contiguous group of bins is representative of that signal (one way would be to look for minima in magnitude left and right). Now for correct frequency scaling, you need to move that whole group up or down (as determined by the ratio, e.g. 2 for one octave up) *** but without scaling the group itself ***. In other words, if bin k moves to 2*k, then bin k-1 moves to 2*k-1 etc. This requires an *interpretation* of the signal: do bins that are close together 1. represent a single frequency signal, or 2. multiple signals that are close together. In case (1) the envelope of the signal is represented by the relative magitudes and phases of the adjacent bins. To preserve this envolope (i.e. to correctly reproduce transient signals), these bins need to remain adjacent. Another way to state this that any algorithm that does frequency scaling (or time stretching) needs some way to decide if certain features of the signal need to be interpreted as significant in the time domain or in the frequency domain. The correct decision depends on how a human listener would interpret that feature. It is not even possible to *define* a frequency scaling or time stretching algorithm without at least implicitly defining a way to decide on this. The implicit assumption in the current algorithm is that each bin is an separate feature in the frequency domain, and thus needs to be scaled independently of all others. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

Am 07.06.2014 19:10, schrieb hermann meyer: That's a good point, maybe you find the time to listen to the results of this plug, that is what I do during the work on it, and, I'm very, very pleased with the result.

On Sun, Jun 08, 2014 at 06:38:50AM +0200, hermann meyer wrote: You're missing the point. Which is that the frequency info *should* be used to decide how to map bins to a new frequency. Also, it's easy to reduce CPU load by letting the whole thing run at a quarter of the system sample rate. Which means that for one octave down everything above 3 kHz is gone. But I guess CPU load was not the only reason for doing that. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Sun, Jun 08, 2014 at 12:36:17PM +0200, hermann meyer wrote: because that removes most of the broadband junk that would be generated otherwise... True for bass and guitar. Still this algorithm is far from what it could be. I don't blame for you that, it's Bernsee who is missing the consequences of his own analysis (which is valid as far as it goes). Take alook at his table labeled 'pass #5'. The input signal is halfway between two bins. Assume we want one octave up. The expected output signal corresponds exactly to bin 225. For that signal, the output of the analysis FFT would be (similar to 'pass #1): bin amplitude ------------------ 223 0.000 224 0.500 225 1.000 226 0.500 227 0.000 And that is of course also what the correct input to the synthesis IFFT should be. Which is quite different from what the algorithm produces (by scaling each bin individually): bin amplitude ------------------- 222 0.170 223 0.000 224 0.849 225 0.000 226 0.849 227 0.000 228 0.170 The result of this after the IFFT is the correct frequency, but with two periods of the window applied (it will be zero at the center). The frequency values that are calculated provide exactly the information required to avoid this and to do the correct calculation. But it's just thrown away. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

Sorry for the late posting, but I’d also recommend the mod-pitchshifter https://github.com/portalmod/mod-pitchshifter We have developed 4 plugins: Capo ( 1 to 7 semitones up), the SuperCapo (1 to 24 semitones up), Drop (1 to 12 semitones down) and SuperWhammy (continuous travel from -12 to 24 semitones) They are a bit CPU hungry but sound quality is quite good. Hope I’ve helped Gianfranco The MOD Team Em 10/06/2014, à(s) 12:27, rosea grammostola <rosea.grammostola(a)gmail.com> escreveu:

Hi Rosea There was o problem in the makefile that’s just been fixed. It shall work now. Kind regards Gianfranco The MOD Team Em 10/06/2014, à(s) 13:15, rosea grammostola <rosea.grammostola(a)gmail.com> escreveu:

Hi Rosea. Sorry Again. We’ve been experimenting with some compile time details and a arctan table generation was still bugged. André just fixed it. Cheers Gianfranco Em 11/06/2014, à(s) 14:52, rosea grammostola <rosea.grammostola(a)gmail.com> escreveu:

On Wed, Jun 11, 2014 at 07:55:13PM +0200, hermann meyer wrote: There's a paper by Dolson and Laroche (1999) which is a 'must read' for anyone dabbling with phase vocoders. See <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.131.8046> which has a free download link from columbia.edu. Their method does the right calculations even without using the computed frequencies (they wanted to avoid the atan2() calls), but it's possible to do the same thing using them. Hint: if you need the frequencies the Bernsee way, just compute them using bin number as the unit instead of Hz - it simplifies things quite a lot ans also shows much clearer what's going on. This is how it's done in some experimantal code I wrote years ago: for (i = 0; i <= hlen; i++) { x = _F [i][0]; y = _F [i][1]; p = atan2 (y, x) / twopi; // Phase in cycles. d = p - _phase1 [i] - i / div; // Minus previous and expected difference. d -= floorf (d + 0.5); // Reduce to [-0.5...+0.5] _phase1 [i] = p; // Store for next iteration. _freq [i] = i + d * div; // Frequency in bins. _magn [i] = hypotf (x, y); // Magnitude. } where 'div' is the overlap factor, e.g. 4 for 75%. Note this must be a float. I'll let you work out the inverse operation by yourself, you'll notice it's even simpler (as some terms cancel out). But it's not needed when using D&L's method. For code, maybe have a look at Rubberband which may contain interesting things (I don't know, never dared to look as it would probably have me hooked up for weeks experimenting with this sort of algorithms...) Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Thu, Jun 12, 2014 at 10:41:00AM +0100, Chris Cannam wrote: Indeed... I'd be surprised if the patent is actually enforced... There's also a collection of related patents by Fraunhofer.. It sure can. Meanwhile, since you tickled me, I did have a look. I've seen worse :-) There's a more fundamental problem behind this. Suppose you have a sine wave at some frequency F, modulated (i.e. multiplied) by say a 8 Hz sine wave. Assume we want to transpose an octave up. Now is this signal a) just a single frequency (F) with some amplitude modulation on it, or b) two signals, at F-8 and F+8 Hz. Mathematically, and in the analysis spectrum, these are just the same thing. It's a matter of interpretation. In case (a) you'd want a sine at 2*F with the same 8 Hz modulation on it. In case (b) the wanted output is two signals at 2*(F-8) and 2*(F+8) Hz. You have the choice of interpreting the 'detail' in either the time or frequency domains. For high F, our hearing would probably favour (a). But at low frequencies things could be different. 64 Hz and 80 Hz would make a nice major third... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)