Hi,
I've been thinking of writing a pd version of autotune, but before i get started i m wondering if anybody as ever tried doing this? I m assuming they're making a ton of money selling it, so there 's probably not much information available as to how it actually works, but i guess Miller Puckette's Phase vocoder example could be a good starting point.
Cheers!
Pierre
Op 16-08-10 18:21, Pierre Massat schreef:
but i guess Miller Puckette's Phase vocoder example could be a good starting point.
Or this: http://web.mit.edu/tbaran/www/autotalent.html
m
On 08/16/2010 06:21 PM, Pierre Massat wrote:
Hi,
I've been thinking of writing a pd version of autotune, but before i get started i m wondering if anybody as ever tried doing this?
not in pd, but in reaktor and c. combining pitch-detection and a pitchshifter (and some quantization) works quite well, and should be not too hard to do in pd (fiddle and the pitchshifter from the docs). though this is quite good for subtle pitch correction, it does not create the typical, metallic, vocoder-like "cher-effect".
maybe something like taking single-cycle-samples of the input, when a constant pitch is detected, and playing these instead of the original audio would do better, but i have not tried yet. (and i think detecting zero-crossings in pd (vanilla) is rather difficult...)
I m assuming they're making a ton of money selling it, so there 's probably not much information available as to how it actually works, but i guess Miller Puckette's Phase vocoder example could be a good starting point.
i do not think that autotune uses fft-based methods, since it has very little latency (and does not need too much cpu).
bis denn! martin
I have never tried autotune. I gather from what you wrote that it can be used in realtime? It sounds a bit like the whammy pedal for a guitar to me, because the sound is altered. I always thought the signal was split in two parts, one used to analyse the spectrum, and one to analyse the pitch. In this model the pitch would be modified according to some rules and the timbre would be stamped back on it. That's what it sounds like to me, but i may be mistaken to a great extent.
Pierre
2010/8/17 martin brinkmann mnb@martin-brinkmann.de
On 08/16/2010 06:21 PM, Pierre Massat wrote:
Hi,
I've been thinking of writing a pd version of autotune, but before i get started i m wondering if anybody as ever tried doing this?
not in pd, but in reaktor and c. combining pitch-detection and a pitchshifter (and some quantization) works quite well, and should be not too hard to do in pd (fiddle and the pitchshifter from the docs). though this is quite good for subtle pitch correction, it does not create the typical, metallic, vocoder-like "cher-effect".
maybe something like taking single-cycle-samples of the input, when a constant pitch is detected, and playing these instead of the original audio would do better, but i have not tried yet. (and i think detecting zero-crossings in pd (vanilla) is rather difficult...)
I m assuming they're making a ton of money selling it, so there 's probably not much information available as to how it actually works, but i guess Miller Puckette's Phase vocoder example could be a good starting point.
i do not think that autotune uses fft-based methods, since it has very little latency (and does not need too much cpu).
bis denn! martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/17/2010 11:25 AM, Pierre Massat wrote:
I have never tried autotune. I gather from what you wrote that it can be used in realtime?
yes, it adds only very little latency
I always thought the signal was split in two parts, one used to analyse the spectrum, and one to analyse the pitch. In this model the pitch would be modified according to some rules and the timbre would be stamped back on it. That's what it sounds like to me, but i may be mistaken to a great extent.
i am not shure either. probably you (and wikipedia) are right, and autotune uses a phase-vocoder. using millers phase-vocoder with small window-sizes sounds awfull though. but maybe, with waves which are already periodic (like single cycles) it is possible to do without windowing and short fft sizes (like 128 or even 64). i will try this when i have found a way to extract single-cycle waves from audio input in pd...
bis denn! martin
On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
i will try this when i have found a way to extract single-cycle waves from audio input in pd...
Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle.
Of course, there might be waveforms which have several zero crossings per cycle, but the above approach might be a start.
Roman
I don't understand this cycle and zero-crossing thing...
2010/8/17 Roman Haefeli reduzent@gmail.com
On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
i will try this when i have found a way to extract single-cycle waves from audio input in pd...
Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle.
Of course, there might be waveforms which have several zero crossings per cycle, but the above approach might be a start.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2010-08-17 at 13:52 +0200, Pierre Massat wrote:
I don't understand this cycle and zero-crossing thing...
Sorry, this was targeted to the question about how to extract exactly one single cycle of a recording of a periodic waveform. I don't know how this could help in building an autotune-like patch. It might help to build a pitch-shifter, but I rather would go for the pase-vocoder way since I would expect much better results from it.
Roman
2010/8/17 Roman Haefeli reduzent@gmail.com On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
> i will try this when i have found a way to extract > single-cycle waves from audio input in pd... Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle. Of course, there might be waveforms which have several zero crossings per cycle, but the above approach might be a start. Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2010-08-17 at 13:52 +0200, Pierre Massat wrote:
I don't understand this cycle and zero-crossing thing...
Sorry, this was targeted to the question about how to extract exactly one single cycle of a recording of a periodic waveform. I don't know how this could help in building an autotune-like patch. It might help to build a pitch-shifter, but I rather would go for the pase-vocoder way since I would expect much better results from it.
Roman
...and you can use zeroxpos~ to find the zero crossing points within the dsp block.
Ed
2010/8/17 Roman Haefeli reduzent@gmail.com On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
> i will try this when i have found a way to extract > single-cycle waves from audio input in pd... Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle. Of course, there might be waveforms which have several zero crossings per cycle, but the above approach might be a start. Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/17/2010 01:39 PM, Roman Haefeli wrote:
On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
i will try this when i have found a way to extract single-cycle waves from audio input in pd...
Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle.
How would you look for zero crossings? With message based objects such as [until], a counter, [tabread] and comparing to zero? Is that feasible?
(sorry for hijacking the discussion, I am curious about that)
On Tue, 2010-08-17 at 13:59 +0200, Matteo Sisti Sette wrote:
On 08/17/2010 01:39 PM, Roman Haefeli wrote:
On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
i will try this when i have found a way to extract single-cycle waves from audio input in pd...
Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle.
How would you look for zero crossings? With message based objects such as [until], a counter, [tabread] and comparing to zero? Is that feasible?
(sorry for hijacking the discussion, I am curious about that)
yeah, actually that's what I thought about. I guess, one would not compare to zero, but compare to the previous sample and check whether the sign has changed. One could even perform linear (or even polynomial interpolation) to find the subsample accurate location of the crossing.
Roman
I made a cheap vanilla zero crossing patch some time ago. it doesn't work properly if the signal has zero samples between crossings though.
Martin
Roman Haefeli wrote:
On Tue, 2010-08-17 at 13:59 +0200, Matteo Sisti Sette wrote:
On 08/17/2010 01:39 PM, Roman Haefeli wrote:
On Tue, 2010-08-17 at 12:59 +0200, martin brinkmann wrote:
i will try this when i have found a way to extract single-cycle waves from audio input in pd...
Not yet tried it myself, but what about writing live input to a table (for instance with [tabwrite~]) in order to have access to the audio data with message based objects? With those it should be fairly easy to the detect the exact position of a zero crossing. For finding a single cycle, it would be sufficient to find a positive crossing - for instance- and from there find the next one, so you have the exact end points of one single cycle.
How would you look for zero crossings? With message based objects such as [until], a counter, [tabread] and comparing to zero? Is that feasible?
(sorry for hijacking the discussion, I am curious about that)
yeah, actually that's what I thought about. I guess, one would not compare to zero, but compare to the previous sample and check whether the sign has changed. One could even perform linear (or even polynomial interpolation) to find the subsample accurate location of the crossing.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Ed Kelly -
martin brinkmann -
Martin Schied -
Matteo Sisti Sette -
mik -
Pierre Massat -
Roman Haefeli