Deutsch  English  Français  中文 

Logging in is required for posting.

Special forum features: inserting music notation, posting audio recordings.

All Categories > Musipedia > Musipedia Features > Love the idea...but...
Total Posts: 12 - Pages (2): [1] 2
user picture  Author: rt
source site Posted: May 13 2008 - 09:58 AM
follow Subject: re: re: Love the idea...but...
wizofaus wrote:
Another example...this search for the first 7 notes of the Scherzo from Midsummer Night's Dream:[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

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.
user picture Author: rt
Posted: May 05 2008 - 07:32 PM
Subject: re: re: Love the idea...but...
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.


user picture go site Author: rt
here Posted: Apr 17 2008 - 11:36 AM
click here Subject: re: re: Love the idea...but...
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.
Author: wizofaus
Posted: Apr 16 2008 - 07:00 AM
here Subject: re: Love the idea...but...
Another example...this search for the first 7 notes of the Scherzo from Midsummer Night's Dream:[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:[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:

 search Musipedia for this

 search Musipedia for this

 search Musipedia for this

 search Musipedia for this

 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.

source site Author: wizofaus
source Posted: Apr 15 2008 - 12:08 AM
Subject: re: Love the idea...but...
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.
user picture Author: rt
Posted: Apr 14 2008 - 11:49 PM
Subject: re: re: Love the idea...but...
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.
Author: wizofaus
Posted: Apr 14 2008 - 11:33 PM
Subject: re: Love the idea...but...
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...
user picture Author: rt
Posted: Apr 10 2008 - 11:10 PM
Subject: re: re: Love the idea...but...
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.

Author: wizofaus
Posted: Apr 10 2008 - 10:45 PM
Subject: re: Love the idea...but...
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.
user picture Author: rt
Posted: Apr 10 2008 - 05:01 PM
Subject: re: Love the idea...but...

some of the issues you mentioned were indeed caused by introducing the new Flash piano, but some things I could not reproduce.

wizofaus wrote:

However...I put a new melody, then tried searching for it, and a) when entering a search melody it seems only non-relative lilypond mode works, plus you can't use flats, which is a bit annoying and...

Did you try placing a check mark next to "Use flat signs instead of sharp signs"?

wizofaus wrote:

b) it couldn't find my melody. I first deliberately searched for it transposed both in pitch and duration (all notes at double the length I added it), and 10 pages of results, but the melody I just put in wasn't there. Then I tried it exactly as I put it in (r8 g'16 c''16 e''8 e''8 d''8 ais'8 d''8 e''8 / flats not sharps) - and it still didn't find it...lastly I tried including some search terms (name of artist and name of song), but it returned no results at all. The only thing that worked was ONLY searching on the name of the artist, with no notes specified at all.

I can't reproduce this - for example an augmented version is found with no problem:

 search Musipedia for this

As is a transposed and augmented version:

 search Musipedia for this

Could it be that you entered a query that was longer than the piece you put into the database?
"r8 g'16 c''16 e''8 e''8 d''8 ais'8 d''8 e''8" is, for example, more than what you added to the database. Maybe you are right, and items which are shorter than the query should be returned too, if they are similar to part of the query.

wizofaus wrote:

Further, while the flash piano entry looks very nice, it's pretty useless without having the ability to delete and using lilypond notation directly. But it's the default when editing a search, and when switching to the javascript version, you lose your original search.

Still...I like the idea, hope to see it improved in the future.

The Flash piano is useful for quickly entering a query without having to think too hard, and it looks flashy. I am trying to reduce the "bounce rate" (the percentage of visitors who stumble upon Musipedia but look only at the very first page they found) by putting the easiest query method on the front page. Once you know what you are doing, the Lilypond piano might indeed be better, and that has the features you are requesting.

I fixed the problem you mentioned: if you now click on "Edit Query" at the beginning of a result list, you can actually edit the query with the Javascript piano. When I quickly added the Flash piano yesterday, I did not consider the fact that this page was the target page for the "Edit Query" button, which of course lead to the loss of the query. I hope this is the problem you meant?


Total Posts: 12 - Pages (2): [1] 2
You must login to post a message to this conference.

How to insert music:

Add a bit of sheet music, along with a MIDI file, simply by entering note names in Lilypond syntax between the [L] and [/L] tags.
For example, you can try what happens if you enter: [l]g'4 g'4 d''4 d''4 e''4 e''4 d''2[/l] (use the Preview function if you don't actually want to post this).
You can create these lists of note names by clicking on piano keys here.

How to post an audio recording:

If you just want to sing, whistle, or play a melody so that other forum visitors can hear it, follow these steps:

  1. Record your audio here.
  2. You should notice a 32-character hash code, something like: 2a40281c5001c5a7d8c9f57fcdeccfaf
  3. copy this hash code and paste it into a forum post, enclosed in the audio tags, for example: [audio]2a40281c5001c5a7d8c9f57fcdeccfaf[/audio]

How to mark a thread as solved:

If the original question in a thread is solved, please mark it as solved using the "solved" icon (or by just typing [solved] into your post). This makes life easier for people who are willing to identify melodies, since unsolved problems are easier to spot that way. If a problem turns out to not be solved after all, just write [/solved] in a new post, and the thread will be labeled accordingly.