Database search

IMSLP data is currently stored in MediaWiki pages. The core data (works, scores, recordings) should insteac be stored in a relational database such as MySQL. The tables might include:

person
    name, nationality, birth/death dates etc.
work
    title, year, instrumentation
score
    file format, size, and name
    instrumentation
    copyright restriction info
recording
rating
... and so on

Currently IMSLP uses Google for its primary search function. This works OK for finding pieces you already know about, but it's not useful for discovering music.

There's currently a confusing and limited "walker" search mechanism. A more powerful search capability could be provided, based on a SQL database as described above. This would involve forms where the user can constrain for any or all of the database attributes. For example, one could search for

• Scores of piano music by French composers written between 1900 and 1910 for which the average rating is 4 or more.
• String quartets arranged for piano 4 hands.

Multi-score download

I often want to download multiple scores. When I discover a new composer I like, I typically want to download all their solo piano music. Currently this is time-consuming: I have to go through a long list of compositions one at a time, see which ones are for piano, look at the available scans, and download one of them. This requires lots of clicks per score.

It would be nice to be able to download multiple scores at once. For example, a "download all" button for the results of a database search. This would download the files as a .zip file.

If this feature generates excessive load on IMSLP servers (it probably would not) it could be metered (limited to a certain number of MB per download) and/or made available only to subscribers.

Integration with forScore

Currently when I download a score on my iPad, the PDF is displayed in a browser window. I then click an "export" button and choose forScore as the destination. The score then appears in forScore, but with only the filename; there is no associated metadata (composer, title, instrumentation, genre). I have to enter these manually for each score.

Ideally, copying a score from IMSLP to forScore would populate forScore with its metadata. One way to do this is to encode this information in the filename (some IMSLP filenames contain some metadata, but not in a format that can easily be parsed).

The developers of forScore would probably be happy to make the needed (minor) changes to forScore. We'd need to agree on and adopt a new scheme for filenames.

The multi-score download feature described above could also be integrated with forScore.

Scores generated from MusicXML files

Currently, IMSLP primarily offers scores as PDFs - typically scans of printed scores.

Suppose that, instead, a piece is stored as a MusicXML file. MusicXML describes the structure of a score - the noteheads, stems, bars, slurs, accidentals etc. - rather than a graphical image of the score. MusicXML is a standardized format. All major score editing programs - such as the commercial Sibelius and Finale and the open-source MuseScore - can read and write MusicXML (each of them has its own variant which adds features not in the standard).

Compared to PDF format, MusicXML presents many possibilities for the user of a score:

• The user can format the score as they desire: with more or less space between notes and staves, in landscape or portrait aspect ratio, with larger or smaller noteheads, and so on.
• If the score is for a multi-instrument piece, separate parts for each instrument can easily be generated.
• Fingerings or other annotations can be a stored in separate files and layered on the basic score.

There are two ways to implement this. The first is for IMSLP to offer MusicXML files for direct download. Users would need to have a MusicXML renderer (such as MuseScore) installed on their device.

A second way is for IMSLP to store scores as MusicXML, but to offer them for download as PDFs. The user could specify options (such as those listed above) for how they want the score to appear. This could be implemented by running MuseScore on IMSLP servers (working in "headless" mode) and using it to create PDFs on demand.

Enhanced music discovery

Typically, the way I discover a piece (or composer) is:

• A friend tells me about it
• I hear it on the radio
• I hear it at a concert
• YouTube recommends it

Then I go to IMSLP to find the score.

IMSLP by itself is not very useful for discovering music you don't know already. But it could be.

IMSLP has essentially three kinds of music: a) pieces by well-known dead composers; b) pieces by little-known dead composers; c) pieces by living composers.

How can I find something I don't already know about, possibly by a composer I haven't heard of? "Show random item" lets me find new things, but they tend to be things that I don't like or are for the wrong instrumentation.

If database search (see above) is supported, a "show random query result" option could be provided; this would improve the efficiency of random discovery.

A better approach would be to let users rate (1 to 5 stars, say) composers and pieces. Users could then do queries on (say) instrumentation, genre, and year, and view the results ordered by rating. This would let people find appropriate pieces by highly-rated little-known and living composers.

A still better approach would be to use collaborative filtering, so that users can find music that matches their individual tastes.

Personal features

Ratings, comments

Users can:

• Rate works on a 1 to N scale. Of course, this is a simplification: ones reaction to music is multidimensional, and you might like one movement but not another. But we need something.
• Comment on works.
• Rate and comment on composers.
• Rate and comment on performers and ensembles.
• Rate and comment on recordings.

Comments may be problematic. When you let people enter text on a web site, you get spammers and trolls. What does YouTube do?

Ratings can be used to order search results and make recommendations. They don't have to be shown explicitly.

We want to encourage people to rate and comment. Some kind of reward system - reputation, badges etc.

Collections/bookmarks

In addition to (or instead of) ratings, a user can collect (or tag) composers, works, recordings, etc. For example, suppose you find an interesting composer while browsing. You can bookmark them so that you can go back later and look at their works in more detail.

History

Keep track of what the user has looked at, let them view it. (like YouTube history).

Social functions

IMSLP could serve as musical nexus as well as a library. Lots of classical musicians - both composers and performers - use IMSLP. It could allow and encourage them to communicate with each other - for example, to let performers commission compositions or form chamber groups. This could be done by combining IMSLP with Music Match.

Performances and programs

IMSLP could store the programs from upcoming (and past) concerts, perhaps partnering with organizations (conservatories, concert series, Groupmuse) to populate this.

This could serve as a directory of upcoming concerts.

The data could be used to make recommendations.

The page for a work could show when it had been performed.