musipedia.org// ?
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: 13 - Pages (2): [1] 2
 Author: margeritta
source site Posted: Oct 04 2018 - 03:13 AM
follow Subject: re: Love the idea...but...
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.
Plex Kodi Lucky Patcher
user picture Author: rt
Posted: May 13 2008 - 09:58 AM
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:

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


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 go site Author: rt
here Posted: May 05 2008 - 07:32 PM
click here 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.

Cheers,

Rainer
user picture Author: rt
Posted: Apr 17 2008 - 11:36 AM
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.
http://www.ruth-moschner-fanclub.de/link.php?url=https://www.ymlp111.net/ Author: wizofaus
Posted: Apr 16 2008 - 07:00 AM
Subject: re: Love the idea...but...
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.

Author: wizofaus
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.

Cheers,
Rainer
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.
Total Posts: 13 - 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.