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

Search

Users

watch thread

All Categories > Musipedia > Musipedia Features > The Parsons code search is too restrictive

Total Posts: 8 - Pages (1): [1]

Author: Ivo Bouwmans
Posted: May 18 2005 - 01:03 PM
Subject: Re: The Parsons code search is too restrictive

Another idea would be to (also) allow 8 for up, 2 for down and 5 for repeat. Then you could enter the code much more intuitively by using the arrows on the numeric key pad with NumLock on. And the software would translate *85888282 into * URUUUDUD , which would remain the format in which the contour is stored.
(I'm almost sure this would not change the accuracy of the automatic detection of textual search terms in the contour field.)

Author: Rainer
Posted: May 18 2005 - 11:42 AM
Subject: Re: The Parsons code search is too restrictive

True. I followed the convention in Parsons' book from the Seventies by allowing a star there. But in order to not confuse people who did not read that book, I made it optional. Actually, I just ignore everything that is not D, U, or R. On top of that, if a contour mostly contains other stuff than D, U, or R, I assume (most of the time correctly) that someone got confused and entered a textual search term like lyrics, title, or composer into the contour field. In that case, I act as if it had been entered in the text search field. This is, by the way, also handy for the Firefox plugin, which has to work with just one field, but supports both contour searches and text searches (just not a combination of the two - for that you have to go to the search form).

Author: Ivo Bouwmans
Posted: May 18 2005 - 09:36 AM
Subject: Re: The Parsons code search is too restrictive

That * represents the FIRST note of the music, which is, obviously, neither 'up' nor 'down', and certainly not 'repeated'.
:-)

Author: Blue Cat
Posted: May 17 2005 - 09:59 PM
Subject: Re: The Parsons code search is too restrictive

That seems like a good idea.
Apropos confusing: I have *already* been confused by the asterisk at the beginning of the search string - it seems that it makes no difference if it's there or missing. But this seems to be intented. (Maybe there are people who are not confused by this?)

Author: Rainer
Posted: May 17 2005 - 03:21 PM
Subject: Re: The Parsons code search is too restrictive

Good idea. Maybe I'll use a check box instead, though, since I am not planning to add wildcard support anywhere else in the string, and it might be confusing to allow putting one at the beginning but not anywhere else.

Author: Ivo Bouwmans
Posted: May 16 2005 - 09:25 PM
Subject: Re: The Parsons code search is too restrictive

A wildcard (e.g. a question mark) might help here:
?* RUDRDRRR
could mean that you do not remember the first part, so you *know* you will get more false positives, but at least you *can* search.

Author: Rainer
Posted: May 08 2005 - 12:28 PM
Subject: Re: The Parsons code search is too restrictive

Good point. On the other hand, the Parsons code is not very restrictive since it is just the gross contour, so I am a bit afraid of lots of false positives if I allow matches to occur anywhere in the string.
I'll think about it and experiment a bit. I have some ideas like e. g. introducing a new component to the distance measure: the length of the matched string.
If I would not do that, everything in the database would match with distance zero. The naive approach, after all, would be:
- instead of just indexing the complete Parsons codes, also index every postfix of Parsons codes in the database (example: RRRRRRRRRRRUDRDRRR , RRRRRRRRRRUDRDRRR , RRRRRRRRRUDRDRRR , ..., RUDRDRRR , UDRDRRR , DRDRRR , RDRRR , DRRR , RRR, RR, R).
- search the list of all postfixes.
- Result: especially the short postfixes will almost always match perfectly.

So, if I reward long matching strings and punish short ones, the overall result might be reasonable.

Author: Blue Cat
Posted: May 08 2005 - 12:58 AM
Subject: The Parsons code search is too restrictive

You can't find tunes if their Parsons code starts earlier than what you are looking for.
Example: If I search for
* RRRRRRRRRRRUDRDRRR
an entry about Chopin's funeral march is shown.
If, however, I only remember the second part of this theme and thus I search for
* RRRUDRDRRR
I won't find the entry. (A different entry is found.)
I believe the second search should find the first result as well, because the second search term is contained in the first search term. Otherwise you would need to create entries for each sub-theme that someone might be searching.

Total Posts: 8 - Pages (1): [1]

Click here for a complete list of threads

You must login to post a message to this conference.

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.

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]

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.