pYIN — pitch and note tracking in monophonic audio

I did that, in branch "interactive" -- Chris, could you maybe have a look, please?

This is a very hacky way of getting some interaction into the Vamp plugin.

But it works on the one test file I used (see testdata/donttellme.wav), and here's what happens if you've compiled from the "interactive" branch:

1. Load the test file into Sonic Visualiser
2. Use the pYIN plugin with default parameters to extract the smoothed melody line.
   • the last note will have an octave error (1 octave higher than actually sung)
3. Extract the melody line once more, but now with program "donttellme"
   • program donttellme sets selects the parameters such that the melody extraction is constrained to a certain frequency range on the last note
   • output will be correct-er

Now, of course in general you don't need a program to set these parameters, I just wrote one for demonstration purposes.
Even more generally, I think this way of dealing with things is not exactly what we'll need for Tony, but it shows that something can be done.

I closed the branch interactive because that was all rubbish, in the end.

The work is now in branch "tony" (see also https://code.soundsoftware.ac.uk/issues/848).

Today I changed the format of the Vamp output, i.e. it's now a fixed matrix with N=20 bins representing candidates.

Usually there are M < N actual unique candidates, so I fill only the first M bins with values, i.e. the first row of bins that contains only zeros marks the end of the useful output.

Oh, after our conversation yesterday I thought I was going to do that (the matrix output). In fact I have done it, as well, but being at a conference without good wifi I haven't pushed it yet. Will try to resolve the differences at some point.

Ah, that's what you get when you talk...!

Chris, I had to resolve some conflicts -- change set 43.

I hope I didn't break much and it still does what you meant it to do -- does it?

Sorry, I should have made a note here when I pushed that last change.

You didn't need to merge anything -- I closed the branch that you were on (one of two anonymous branches of the tony named branch) so all you needed to do was update to the other one.

"hg update -rtony" would have done it, because there was only one (non-closed) head for the tony branch, namely the one I made.

But my mistake was in forgetting to tell you about it, as there's no particular reason you should have realised. You wouldn't have seen what happened unless you had looked at the history in easyhg or whatever (which would have said you were "at the head of a closed branch" and showed only the other one) and even then you might not have twigged what it meant or what to do about it.

So, sorry about that. Your merge commit re-opened the closed branch that you committed on, but that's all right because your merge seems to have been fine. So the current state of the repo is perfectly OK and we don't need to worry about it. There's now only the one head and it's the merged one.

As an aside -- you can't use the short numbers (things like "change set 43") when discussing changes with another developer, you have to use the hash (or at least the first few characters of it). The short numbers may be in a different order in someone else's repo, depending on what order their changes were pulled in. They only exist for quick reference in a single local repo.

Ok, super, thanks for the explanations. They really do help -- though admittedly usually not the first time round... so: I shall try to remember some of this.