Towards a system of organization of digital music files: The La Folia model
Some of the pleasure and the difficulty in music is that it is so ... fluid. Not only is it an art of time, but musical objects are truly multi-dimensional and the limits and frontiers between those dimensions is most of the time a matter of appreciation. Add to that the multiplicity of new formats -- digital scores, printable scores, MIDI renditions, XML, audio files in MP3/4, and videos -- that have grown out of our computer age, and you have a decently complex problem to organize and link all the various and different facets of what we used to call simply a tune, a melody, or a piece of music.
The problem is of course more than just theoretical when you have to actually program an interface that seeks to be comprehensive enough. The question of classification of the various dimensions that used to be simply a score or a performance directly affects the code at the deepest possible level. Add to that that no matter how well you design your logical framework, when confronted with a fair amount of data, exceptions top the rule inevitably pop up and they often necessitate a revision of the basic premisses.
In a way, sticking music in a computer environment is a bit like sticking a camel in your fridge. One part or another of the animal will stick out and prevent you from closing the door shut. However, there is no other solution for a software designer than to rely on a preliminary organization model that makes some sense at some level, and hope that the other levels will indeed cooperate.
This WEB site, pretty much as soon as I opened it, is already incomplete and obsolete. The quality and nature of the files that constitutes its body is pretty much irrelevent, as long as they belong to some fairly accepted and current formats. While you may be impressed by the sheer number of lute music files (out of all things!) my real interest was in creating the framework that would bind not just those files among themseleves but also the users and creators. Although, it was an essential quality of the files in question that be real, diverse, multi-format and over all decent and esthetically pleasant. It helps.
Why call my model La Folia, or in English The leaf, or better a music sheet. The basic atom in this model is a single piece of music. Already problems occur to us: what format, which part, whose author, what title? So rather than being a very concrete object as we are used to think about sheet music, the atom I have chosen is acvtually a rather abstract entity. Like la Folia, the famous historic piece, it does not have an author, a clearly defined format, and really very little reality of its own. At best, it has a fairly common harmonic structure that is shared among all the objects that are also called la folia. Maybe we can call it a tune, or an entity - the word I have chosen for my model.
But of course no piece of music ever comes to us as the abstract animal I have described above. The abstraction is retro-active rather than pro-active. First you figure out that both Vivaldi and Marin Marais composed a piece called la folia, then you figure out what it is in that piece that deserves to link the two together at a certain level.
This is the second level of embodiment of a piece of music that I have defined: a composition. A composition is an entity that actually has a defined and unique structure, and usually also an author. Not that a composition is yet a concrete object but it comes closer. You can tell la Folia by Vivaldi from that by Marais, so that at the composition level all of them are distinct and different. This, more than the fact that it may have an actual, well identified author is what makes a composition.
So, entities allow you to group pieces of music together, while compositions allow you to distinguish between them. The final level of actualization of a piece of music is its performance. This is the final stage by which the piece of music actually reaches our senses, ears and eyes and touch. Rarely smell, though it was done at least once or twice.
As you can see, I have somewhat considerably extended the notion of performance to include what we normally call scores. That notion also crosses that of file format: a composition is represented by a conglomerate of formats defined by their functionality: read, play and listen. Essentially on this site, digital scores (django, fronimo, tab, sibelius,finale, etc.), printable copies: PDF, and audio files, mostly MIDI. This does not mean the framework is not open to other formats though, but it is much easier to provide derivative copies from a single score, such as an automatically generated MIDI rendition, than to link a printable copy to a track on a CD or evevn a video on YouTube. Not to mention copyrights issues.
Derivatives are the last level I want to talk about here: a derivative is a digital file that is generated by another: whether it is a finale score createdc from a MusicXML file, or more commonly, a PDF generated by a digital score editor. The notion of derivative also implies a tree structure, since there has to be an Uhr file from which others are derived.
In fact we can summarize simply like this:
-- an entity consists of several compositions
-- a composition consists of several performances
-- a performance may consist of several physical and digital renditions
This is great! A simple enough scheme, ready for some supporting code! So where are collections coming from? In reality, most music scores come bundled into collections: whether a CD, a book, or a televised series, or a Django format file. The way I chose to see this relationship is a conglomerate of scores/performances/formats. That grouping involves a collection of compositions bound by a certain file format, as well as quite possibly their own derivatives.
But then, if you can group together performance files, can you not also group compositions in a parallel way?
One traditional way of doing that is to define a group of composition based on their author. This is usually known as an Opus. Similarly, and to keep things fairly parallel, entities can be grouped into genres, based on the abstract harmonic structure I mentioned at the beginning.
In the end we have a multi-dimensional shema like below:
| Entities | Compositions | Performances (scores) |
| Genres | Opi | Collections |
The whole purpose of this fairly complex scheme is to allow navigating from one dimension to another easily: concretely, for the end user, this means not just finding a piece of music in one format, but finding different functionalities of that piece, and easily branching out or threading to where they want to go, as well as in directions they did not anticipate.
The CakePHP framework used to develop the site greatly helped, because it easily defines the type of relationship between the categories. In CakePHP talk, the schema above is a double set of relationships:
--An entity hasMany-> Compositions which hasMany-> Performances
--A performance belongsTo -> a composition which belongsTo-> an entity
On the vertical side the relationships are the same:
-- An entity belongsTo-> Genre, and a Genre hasMany entities
-- A composition belongsTo->an opus, and an Opus usually hasMany compositions
-- A performance belongsTo->a collection and a Collection hasMany performances
So the abstract schema provided by the CakePHP framework greatly helped in this project by providing a set of abstract, logical relationship that only needed to be applied.
To conclude, I hope these notes will help you better navigate the site and make some informed judgments when trying to insert your documents in the site.
WEB statistics