yes, I just started some work on the algorithm.

This is now fixed. With this query, the expected piece turns up at the top of the list with the current version of the hybrid pitch/rhythm search algorithm.

Also, for the JavaScript keyboard, I have now set the default rhythm/pitch preference to 0.4 (pitch gets 60 %, rhythm only 40 %). I agree with you that pitch should by default be weighted more strongly than rhythm. Still need to change the default for the Flash piano. But one can now easily correct this ratio after searching.

Finally, I got a new search algorithm online. The Flash search (used on the main page) now works with a pitch and a rhythm component.
If a search result seems unsatisfactory, one can use the slider at the top of the result list to change the proportions of these two components and run the search again (with the existing melody query, just with different weights for rhythm and pitch).

I might switch the Javascript keyboard to that search algorithm as well, unless there is strong opposition to this. I personally have the impression that the new algorithm works better, especially if one has some errors in the query. Also, having some control over whether rhythm or pitch should be given more weight seems nice.

Cheers,

Rainer

Yes, this is very helpful, thanks!

I noticed one stupid bug that probably greatly contributes to your dislike of the rhythm component: the rhythm index currently is not updated after editing. So, if you search for anything new or edited, it will either get a very bad rhythm score (because it does not match at all), or an incorrect rhythm score (the old one that was correct before editing). For me it seemed to work fine because this only affects a small percentage of the database, but for you it must have looked quite bad if you searched for things you had just edited.

I am going to fix this and at the same time completely decouple the index updating and editing tasks: editing or adding something will just set a "dirty" flag, and a separate process will watch over the data and re-index anything "dirty". That way, the indexing effort does not need to happen while you are editing, which should make the server seem slightly less sluggish. Instead, it can happen a few seconds later, when you have already gotten another HTML page back from the server, and it can also be limited to times when the load is low. The only disadvantage of this approach is that it could take a few seconds or minutes until newly edited data are searchable.

Another example...this search for the first 7 notes of the Scherzo from Midsummer Night's Dream:

http://www.musipedia.org/search.0.html?sourceid=flash&tx_mpsearch_pi1[submit_button]=Search&tx_mpsearch_pi1[pc]=hum%2000-113-100/481-111-100/806-109-100/1121-111-100/1690-108-100/2028-109-100/2693-106-100&coll=m&rvp=0.5&filtertext=&onlymatchfrom=-1

turns up a full page of melodies with the same contour, before listing a melody that uses exactly the same sequence of pitches.
If I edit the url so that the rhythm is exactly correct:

http://www.musipedia.org/search.0.html?sourceid=flash&tx_mpsearch_pi1[submit_button]=Search&tx_mpsearch_pi1[pc]=hum%2000-113-100/400-111-100/600-109-100/800-111-100/1000-108-100/1200-109-100/1600-106-100&coll=m&rvp=0.5&filtertext=&onlymatchfrom=-1

it returns the Scherzo as the first hit.

The rvp value doesn't seem to make any difference unless you set it to nearly 1.0, when it starts returning melodies that bear no obvious resemblance at all to the search pattern.

Again, just my opinion, but I would really expect the default weighting would be overwhelming be towards exact pitch relationships. I'd then probably be looking for cases where the fragment matches close to the beginning of the melody in the database, and then only after that looking at rhythmic similarity. For instance, if you had these 5 melodies in the database:

1.
 
 search Musipedia for this

2.
 
 search Musipedia for this

3.
 
 search Musipedia for this

4.
 
 search Musipedia for this

5.
 
 search Musipedia for this

And the user searched for something like:


 
 search Musipedia for this

Then I'd expect the order to be:

1. exact pitch sequence, starting from second note
4. exact pitch sequence, starting from second note, less rhymically similar
3. exact pitch sequence, starting from third note
5. similar pitch sequence, exact rhythmic match from 2nd note
2. exact contour match, but still arguably the least similar overall

(I wouldn't particularly care if 2. & 5. appeared in reverse order).

Hope this helps.

Just as an example of a melody I can't get it to find - if I search for the first 7 notes of somewhere over the rainbow (g g' f# d e f# g), via either the flash or javascript piano, it doesn't seem to find it at all, except if I put the exact rhythm in via the javascript piano method.
I really think exact pitch relationships should take top priority - so that searching for "g g' f# d e f# g" should first turn all melodies that contain that series of pitches (allowing for transposition of course), regardless of rhythm.

yes. I just started some work on the algorithm. Right now, there are 4 variants in use:

- Rhythm only: used for "query by tapping". Works well, as far as I know.
- Contour only ("Parsons Code"): works well within the natural limits of this method.
- rhythm+pitch: used for the Javascript piano and also for "draw notes". Works well for patterns that are reasonably similar to the intended patterns. Not so good for larger deviations. Pays close attention both to rhythm and pitch, but does not allow the user to say what should be more important - rhythm or pitch.
- new hybrid rhythm: used for the Flash piano. Allows the user to specify the importance of rhythm versus pitch (that's the somewhat cryptically named "Rvp" dropdown box). Currently uses only Parsons Code for the pitch component. The rhythm component is identical to the "rhythm only" search. Will soon be a bit more specific about intervals.

I think the problem is with the "near the beginning" mode. It seems very fussy - if the melody in the database starts with a rest, then it won't match even exactly the first 5 notes without the rest.

Actually, in general, the matching algorithm seems to need some work - it seems to pay a lot of attention to contours and not much to specific pitches...

Now I see what you mean with the bug in the search algorithm. Need to look into this.

I am thinking about putting a new search algorithm out pretty soon anyways - one where you can determine yourself whether it should pay more attention to rhythm or to the pitches.

About Javascript: you mean, you would like to be able to enter "bes" instead of "ais" and so forth into the text field? Should be no problem to implement.

Cheers,
Rainer

I think I figured out why you cant use flat node names (bes) or relative mode when entering the search fragment - it's because you're using some custom javascript code to generate the preview, rather than using lilypond itself. Understandable from a technical perspective. However I reckon implementing the code to support relative mode and flats in javascript is probably worth it!)

The search does appear to work fine when you only use the first 6 notes (c d e e d bes), but as soon as you include the 7th (the second d) it fails. I'm confused as to why you say the pattern I included in my original post is longer than that in the database - they look exactly the same to me.