Hi,
Is there a place where one can find detailed documentation about how fiddle~ behaves? For example, a less cryptic explanation of the meaning of the "vibrato" parameters than is found in the help patch? And of how it decides when to output a new "cooked" picth value?
I already checked M.Puckette's article cited in the help patch, but it doesn't explain much more (from a behaviour/usage point of view of course).
Another question about fiddle. I'd like to be able to distinguish between a signal with a pitch and a signal without a picth. It seems to me that fiddle always outputs its "best guess" no matter how reliable it is. Is there a way to tell it to output a pitch when it thinks it is reliable, and a 0 when it thinks it isn't?
I think some pitch tracking algorithms do provide an estimation of the "quality" of the calculated pitch - i guess it is not the case of fiddle, is it?
Any suggestion to obtain an estimation of whether the signal has a pitch or not?
I thought I may use the third outlet and evaluate whether it outputs a very randomly-varying number; however, with a [noise~] as input, it mostly outputs values between 90 and 110 and some 0 every once in a while.....
Thanks in advance m.
Hi,
On Fri, 2008-01-11 at 13:57 +0100, matteo sisti sette wrote:
Another question about fiddle. I'd like to be able to distinguish between a signal with a pitch and a signal without a picth. It seems to me that fiddle always outputs its "best guess" no matter how reliable it is.
Actually that's not quite true. fiddle~ doesn't output anything at all from its first outlet unless it's pretty certain a pitch has been found.
However, it does continuously output the first estimated peak location it uses to make its pitch calculation from its third outlet. It will also output 0 as a peak location if it can't find a peak, so you can make a pitched vs unpitched certainty estimator like the one in the attached patch giving 3 certainty levels (0.5 is unsure).
I thought I may use the third outlet and evaluate whether it outputs a very randomly-varying number; however, with a [noise~] as input, it mostly outputs values between 90 and 110 and some 0 every once in a while.....
With the default fiddle~ settings, it seems to output 0 about 15% of the time, which seems quite a lot to me.
Anyhow, I think this is a case of using the wrong tool for the job. Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not to measure noisiness. There are other tools to measure this - I find spectral irregularity to be quite a good noisiness metric, but there are several others. If you are interested in this, perhaps take a look at the libxtract feature extraction library, which comes with PD external that wraps its functionality.
Jamie
Another question about fiddle. I'd like to be able to distinguish between a signal with a pitch and a signal without a picth. It seems to me that fiddle always outputs its "best guess" no matter how reliable it is.
Actually that's not quite true. fiddle~ doesn't output anything at all from its first outlet unless it's pretty certain a pitch has been found.
Yes, he outputs a pitch from the first outlet when he finds one, but then never outputs anything to tell you that a pitch is no more present. When a new stable pitch is found, it is output through the first outlet, but how do you know whether the first pitch had remained stable untill that moment or if it had stopped existing before? That's why I was looking at the third outlet instead.
However, it does continuously output the first estimated peak location it uses to make its pitch calculation from its third outlet. It will also output 0 as a peak location if it can't find a peak,
Yes but it seems to me it is a bit too "tolerant" in saying he can find a pitch, and I was wondering whether there is a way to set the "tolerance".
With the default fiddle~ settings, it seems to output 0 about 15% of the time, which seems quite a lot to me.
With pure noise as an input? Quite a lot????? IF it is supposed to output 0 when it can't find a pitch, I would expect to output 0 about 90% of the time with pure noise as input!!
Anyhow, I think this is a case of using the wrong tool for the job. Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not to measure noisiness. There are other tools to measure this
Maybe. The fact is that I do want to find a pitch, but I consider "none" as a possible value, i.e. I want to find the pitch if the signal reasonably has one, and ignore it when it is most probably garbage.
I thought there were two kinds of pitch trackers: those which do have a "none" value, and those which assume a pitch must exist and output their best estimation always. (well and a "fuzzy" third type, which always give both a pitch value and an estimated reliability value).
I don't fully understant to which type fiddle belongs, because on one side, it does distinguish whether he does or not detect a stable pitch, since it only outputs a "cooked" pitch when it becomes stable. However, a new cooked pitch is output (AFAIU) when the pitch changes to a new one (and here I don't understand well what it means, for example what is supposed to happen if the pitch changes very very slowly but continuously...) and this involves some mechanism to deal with vibrato (one more thing I don't understand how it works), so I can't imagine it doesn't detect when a stable pitch stops existing, and I would expect to output this information in some way related to the cooked pitch stuff....... That is, it is like he says "NOW I detect a stable pitch of 57.2 ..... ..... ....and NOW I detect a pitch of 60". And what happened in the meantime????
However I'll look at the documentation other people pointed me to, so I'll probably understand all this a bit better.
I find spectral irregularity to be quite a good noisiness metric,
How do you measure (or define) spectral irregularity?
I may want to use spectral irregularity to estimate whether the signal is non-noisy and then use fiddle to get the pitch when it is supposed to exist; I just thought that nobody better than the pitchtracker itself could tell me how difficult it is for it to find the pitch!
but there are several others. If you are interested in this, perhaps take a look at the libxtract feature extraction library, which comes with PD external that wraps its functionality.
Thank you so much. I'll have a look
HI all,
I don't know any canonical way to decide when a note is finished, except to notice that a new note has started. But it's probably possible to use the "discrete" output of fiddle~ to catch note-on events and then make up criteria that define endings of notes based on either pitch deviation or falling envelope.
By the way, the new sigmund~ object outperforms fiddle~ on most tasks and might be worth trying. It's probably best to use the newest one (out of pd 0.41 test).
cheers Miller
On Fri, Jan 11, 2008 at 06:30:08PM +0100, Matteo Sisti Sette wrote:
Another question about fiddle. I'd like to be able to distinguish between a signal with a pitch and a signal without a picth. It seems to me that fiddle always outputs its "best guess" no matter how reliable it is.
Actually that's not quite true. fiddle~ doesn't output anything at all from its first outlet unless it's pretty certain a pitch has been found.
Yes, he outputs a pitch from the first outlet when he finds one, but then never outputs anything to tell you that a pitch is no more present. When a new stable pitch is found, it is output through the first outlet, but how do you know whether the first pitch had remained stable untill that moment or if it had stopped existing before? That's why I was looking at the third outlet instead.
However, it does continuously output the first estimated peak location it uses to make its pitch calculation from its third outlet. It will also output 0 as a peak location if it can't find a peak,
Yes but it seems to me it is a bit too "tolerant" in saying he can find a pitch, and I was wondering whether there is a way to set the "tolerance".
With the default fiddle~ settings, it seems to output 0 about 15% of the time, which seems quite a lot to me.
With pure noise as an input? Quite a lot????? IF it is supposed to output 0 when it can't find a pitch, I would expect to output 0 about 90% of the time with pure noise as input!!
Anyhow, I think this is a case of using the wrong tool for the job. Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not to measure noisiness. There are other tools to measure this
Maybe. The fact is that I do want to find a pitch, but I consider "none" as a possible value, i.e. I want to find the pitch if the signal reasonably has one, and ignore it when it is most probably garbage.
I thought there were two kinds of pitch trackers: those which do have a "none" value, and those which assume a pitch must exist and output their best estimation always. (well and a "fuzzy" third type, which always give both a pitch value and an estimated reliability value).
I don't fully understant to which type fiddle belongs, because on one side, it does distinguish whether he does or not detect a stable pitch, since it only outputs a "cooked" pitch when it becomes stable. However, a new cooked pitch is output (AFAIU) when the pitch changes to a new one (and here I don't understand well what it means, for example what is supposed to happen if the pitch changes very very slowly but continuously...) and this involves some mechanism to deal with vibrato (one more thing I don't understand how it works), so I can't imagine it doesn't detect when a stable pitch stops existing, and I would expect to output this information in some way related to the cooked pitch stuff....... That is, it is like he says "NOW I detect a stable pitch of 57.2 ..... ..... ....and NOW I detect a pitch of 60". And what happened in the meantime????
However I'll look at the documentation other people pointed me to, so I'll probably understand all this a bit better.
I find spectral irregularity to be quite a good noisiness metric,
How do you measure (or define) spectral irregularity?
I may want to use spectral irregularity to estimate whether the signal is non-noisy and then use fiddle to get the pitch when it is supposed to exist; I just thought that nobody better than the pitchtracker itself could tell me how difficult it is for it to find the pitch!
but there are several others. If you are interested in this, perhaps take a look at the libxtract feature extraction library, which comes with PD external that wraps its functionality.
Thank you so much. I'll have a look
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
First of all thanks to everybody for the clarifications and suggestions I received.
2008/1/11, Miller Puckette mpuckett@imusic1.ucsd.edu:
I don't know any canonical way to decide when a note is finished, except to notice that a new note has started.
That's very interesting: it reveals to me how wrong my way of conceiving the whole thing from the beginning is.
I still can't understand too well how it works. I mean, apart from what I was trying to do and no matter whether fiddle is or isn't possibly useful for doing that, I am now simply trying to understand just how fiddle works.
My idea of "understanding" is being able to predict the expected (or ideal) behaviour of fiddle in response to a given input.
For example, how should I expect it to behave if I send it a phasor (to say a non-sinusoidal but clean-pitched sound) with a pitch that increases slowly but steadily up to several semitones or even octaves? What if the same increase in pitch is much faster? How do the "vibrato" parameters influence? Another example: what about re-attacks? When should I expect a repetition of the same note to appear as a repeated pitch on the cooked-pitch (first) outlet, and when should I instead expect only a bang in the attack outlet?
Is all this kind of things explained in detail somewhere? Maybe all or part of this is not specifical to Fiddle but generar pitchtracking theory stuff?
Or do I have to look at the source code? :scared:
I did try to play with it and observe in order to find some answers, but I'm too lost to be able to draw conclusions from tests (too many mutually interfering questions).
By the way, I had a look at the examples mentioned by Hans Roels (I only found example patches, no plain explanations) but I'm afraid my uncertainties are at a deeper level.
Thanks again m.
I don't know if this helps, but I wrote a paper, "score following using the sung voice" that has some info on that:
http://crca.ucsd.edu/~msp/Publications//icmc95.ps
cheers Miller
On Thu, Jan 17, 2008 at 04:06:59PM +0100, matteo sisti sette wrote:
First of all thanks to everybody for the clarifications and suggestions I received.
2008/1/11, Miller Puckette mpuckett@imusic1.ucsd.edu:
I don't know any canonical way to decide when a note is finished, except to notice that a new note has started.
That's very interesting: it reveals to me how wrong my way of conceiving the whole thing from the beginning is.
I still can't understand too well how it works. I mean, apart from what I was trying to do and no matter whether fiddle is or isn't possibly useful for doing that, I am now simply trying to understand just how fiddle works.
My idea of "understanding" is being able to predict the expected (or ideal) behaviour of fiddle in response to a given input.
For example, how should I expect it to behave if I send it a phasor (to say a non-sinusoidal but clean-pitched sound) with a pitch that increases slowly but steadily up to several semitones or even octaves? What if the same increase in pitch is much faster? How do the "vibrato" parameters influence? Another example: what about re-attacks? When should I expect a repetition of the same note to appear as a repeated pitch on the cooked-pitch (first) outlet, and when should I instead expect only a bang in the attack outlet?
Is all this kind of things explained in detail somewhere? Maybe all or part of this is not specifical to Fiddle but generar pitchtracking theory stuff?
Or do I have to look at the source code? :scared:
I did try to play with it and observe in order to find some answers, but I'm too lost to be able to draw conclusions from tests (too many mutually interfering questions).
By the way, I had a look at the examples mentioned by Hans Roels (I only found example patches, no plain explanations) but I'm afraid my uncertainties are at a deeper level.
Thanks again m.
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This one's pretty helpful too:
@misc{ puckette98realtime, author = "M. Puckette and T. Apel and D. Zicarelli", title = "Real-time audio analysis tools for Pd and MSP", text = "Puckette, M. S., T. Apel, and D. D. Zicarelli. 1998. Real-time audio analysis tools for Pd and MSP. Proceedings of the International Computer Music Conference. ??-?.", year = "1998", url = "citeseer.ist.psu.edu/puckette98realtime.html" }
Jamie
On Thu, 2008-01-17 at 08:19 -0800, Miller Puckette wrote:
I don't know if this helps, but I wrote a paper, "score following using the sung voice" that has some info on that:
http://crca.ucsd.edu/~msp/Publications//icmc95.ps
cheers Miller
On Thu, Jan 17, 2008 at 04:06:59PM +0100, matteo sisti sette wrote:
First of all thanks to everybody for the clarifications and suggestions I received.
2008/1/11, Miller Puckette mpuckett@imusic1.ucsd.edu:
I don't know any canonical way to decide when a note is finished, except to notice that a new note has started.
That's very interesting: it reveals to me how wrong my way of conceiving the whole thing from the beginning is.
I still can't understand too well how it works. I mean, apart from what I was trying to do and no matter whether fiddle is or isn't possibly useful for doing that, I am now simply trying to understand just how fiddle works.
My idea of "understanding" is being able to predict the expected (or ideal) behaviour of fiddle in response to a given input.
For example, how should I expect it to behave if I send it a phasor (to say a non-sinusoidal but clean-pitched sound) with a pitch that increases slowly but steadily up to several semitones or even octaves? What if the same increase in pitch is much faster? How do the "vibrato" parameters influence? Another example: what about re-attacks? When should I expect a repetition of the same note to appear as a repeated pitch on the cooked-pitch (first) outlet, and when should I instead expect only a bang in the attack outlet?
Is all this kind of things explained in detail somewhere? Maybe all or part of this is not specifical to Fiddle but generar pitchtracking theory stuff?
Or do I have to look at the source code? :scared:
I did try to play with it and observe in order to find some answers, but I'm too lost to be able to draw conclusions from tests (too many mutually interfering questions).
By the way, I had a look at the examples mentioned by Hans Roels (I only found example patches, no plain explanations) but I'm afraid my uncertainties are at a deeper level.
Thanks again m.
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
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
I can't find a online archive of the Music-IR list, but there was
recently a post by Arturo Camacho about a "New pitch estimator" with
link to a PhD dissertation:
http://www.cise.ufl.edu/~acamacho/publications/dissertation.pdf
It might be of interest.
(untested)
Hi !
Does anybody whant to share an article or a document related to the sigmund~ object ?
Thanks in advance.
Cheers, Damien.
Miller Puckette a écrit :
HI all,
I don't know any canonical way to decide when a note is finished, except to notice that a new note has started. But it's probably possible to use the "discrete" output of fiddle~ to catch note-on events and then make up criteria that define endings of notes based on either pitch deviation or falling envelope.
By the way, the new sigmund~ object outperforms fiddle~ on most tasks and might be worth trying. It's probably best to use the newest one (out of pd 0.41 test).
cheers Miller
On Fri, Jan 11, 2008 at 06:30:08PM +0100, Matteo Sisti Sette wrote:
Another question about fiddle. I'd like to be able to distinguish between a signal with a pitch and a signal without a picth. It seems to me that fiddle always outputs its "best guess" no matter how reliable it is.
Actually that's not quite true. fiddle~ doesn't output anything at all
from its first outlet unless it's pretty certain a pitch has been found.
Yes, he outputs a pitch from the first outlet when he finds one, but then never outputs anything to tell you that a pitch is no more present. When a new stable pitch is found, it is output through the first outlet, but how do you know whether the first pitch had remained stable untill that moment or if it had stopped existing before? That's why I was looking at the third outlet instead.
However, it does continuously output the first estimated peak location it uses to make its pitch calculation from its third outlet. It will also output 0 as a peak location if it can't find a peak,
Yes but it seems to me it is a bit too "tolerant" in saying he can find a pitch, and I was wondering whether there is a way to set the "tolerance".
With the default fiddle~ settings, it seems to output 0 about 15% of the time, which seems quite a lot to me.
With pure noise as an input? Quite a lot????? IF it is supposed to output 0 when it can't find a pitch, I would expect to output 0 about 90% of the time with pure noise as input!!
Anyhow, I think this is a case of using the wrong tool for the job. Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not to measure noisiness. There are other tools to measure this
Maybe. The fact is that I do want to find a pitch, but I consider "none" as a possible value, i.e. I want to find the pitch if the signal reasonably has one, and ignore it when it is most probably garbage.
I thought there were two kinds of pitch trackers: those which do have a "none" value, and those which assume a pitch must exist and output their best estimation always. (well and a "fuzzy" third type, which always give both a pitch value and an estimated reliability value).
I don't fully understant to which type fiddle belongs, because on one side, it does distinguish whether he does or not detect a stable pitch, since it only outputs a "cooked" pitch when it becomes stable. However, a new cooked pitch is output (AFAIU) when the pitch changes to a new one (and here I don't understand well what it means, for example what is supposed to happen if the pitch changes very very slowly but continuously...) and this involves some mechanism to deal with vibrato (one more thing I don't understand how it works), so I can't imagine it doesn't detect when a stable pitch stops existing, and I would expect to output this information in some way related to the cooked pitch stuff....... That is, it is like he says "NOW I detect a stable pitch of 57.2 ..... ..... ....and NOW I detect a pitch of 60". And what happened in the meantime????
However I'll look at the documentation other people pointed me to, so I'll probably understand all this a bit better.
I find spectral irregularity to be quite a good noisiness metric,
How do you measure (or define) spectral irregularity?
I may want to use spectral irregularity to estimate whether the signal is non-noisy and then use fiddle to get the pitch when it is supposed to exist; I just thought that nobody better than the pitchtracker itself could tell me how difficult it is for it to find the pitch!
but there are several others. If you are interested in this, perhaps take a look at the libxtract feature extraction library, which comes with PD external that wraps its functionality.
Thank you so much. I'll have a look
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 Fri, 2008-01-11 at 18:30 +0100, Matteo Sisti Sette wrote:
With the default fiddle~ settings, it seems to output 0 about 15% of the time, which seems quite a lot to me.
With pure noise as an input? Quite a lot????? IF it is supposed to output 0 when it can't find a pitch, I would expect to output 0 about 90% of the time with pure noise as input!!
The thing is that fiddle~'s Maximum Liklihood pitch detector, like most other PDAs takes a relatively small 'window' of sample data and tries to find periodicity in it. It doesn't care about anything else.
Most small 'windows' taken from noise generators have some discernable periodicity. There are two important things about this i) the very fact of windowing the signal imposes an artificial periodicity on it, ii) any PDA based on an FFT/STFT assumes that the windowed signal is periodic, because the FFT assumes this. You can try this as an experiment: take a 1024 sample of a noise wave form, and play it back with tabosc~. It will have a disernable sense of pitch.
I said that 15% seems like quite a lot because generally speaking noise tolerance is generally considered to be a good quality in PDAs. Given the same test conditions as I used above, The 'f0' function in libxtract failed to find a fundamental less than 0.5% of the time and over 5000 frames 'failsafe_f0' failed 0% of the time. However, these functions are a _lot_ less efficient than fiddle~ and have different design goals.
Anyhow, I think this is a case of using the wrong tool for the job. Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not to measure noisiness. There are other tools to measure this
Maybe. The fact is that I do want to find a pitch, but I consider "none" as a possible value, i.e. I want to find the pitch if the signal reasonably has one, and ignore it when it is most probably garbage.
I think that's reasonable. Both 'f0' and 'failsafe_f0' give their output on a block-by-block basis, and will give '0' if they can't find a pitch. In addition the function have a return code that indicates whether the function has failed or succeeded, but this isn't accessible from the Pd extern.
I thought there were two kinds of pitch trackers: those which do have a "none" value, and those which assume a pitch must exist and output their best estimation always. (well and a "fuzzy" third type, which always give both a pitch value and an estimated reliability value).
I think the estimated reliability is quite difficult. But should be possible if another metric is used in combination with f0.
How do you measure (or define) spectral irregularity?
There are two definitions, one by Krimphoff (1994), and one by Jensen (1999).
In Latex maths code:
Krimphoff:
Irregularity = \sum_{k=2}^{N-1} |a_k - \frac{a_{k-1} + a_k + a_{k+1}} {3}|
Jensen:
Irregularity = \frac{\sum_{k=1}^{N} (a_k - a_{k+1})} {\sum_{k=1}^N a_k^2}
I may want to use spectral irregularity to estimate whether the signal is non-noisy and then use fiddle to get the pitch when it is supposed to exist; I just thought that nobody better than the pitchtracker itself could tell me how difficult it is for it to find the pitch!
You might want to look at some other features as well, there is quite a good Noisiness measure based on (I think) the spectral flatness measure (SFM) of Bark coefficients.
Jamie
On Fri, 2008-01-11 at 19:59 +0000, Jamie Bullock wrote:
Krimphoff:
Irregularity = \sum_{k=2}^{N-1} |a_k - \frac{a_{k-1} + a_k + a_{k+1}} {3}|
Jensen:
Irregularity = \frac{\sum_{k=1}^{N} (a_k - a_{k+1})} {\sum_{k=1}^N a_k^2}
Where a_k is the amplitude of the kth coefficient in the magnitude spectrum.
Jamie
-
Damien Henry - Voxler -
Jamie Bullock -
Matteo Sisti Sette -
matteo sisti sette
-
Miller Puckette -
Steffen Juul