History:Object Model/Representing Remixes

Thoughts on Representing Remixes in the ObjectModel

Remixes make the layers of the ObjectModel between the ../PerformanceObject and the ../TrackObject a royal pain. Actually remixes would be the only reason to use the ../MixObject at all.

The whole issue can be greatly simplified if a remix is seen as a performance. If we define a remix of being a ../PerformanceObject of its own, this has the following consequences:

• A ../MasterObject belongs to exactly one ../PerformanceObject. Anything that combines multiple performances is a remix and therefore a performance of its own again.
• The ../MixObject can be merged with the ../MasterObject. Defining the boundaries between these two objects was close to impossible.
• Remixes can be modelled by AdvancedRelationships between ../PerformanceObjects

What gets remixed?

A remix doesn't combine different ../MasterObjects. Only bootleg remixes are based on masters. The majority of proper remixes use one or more ../PerformanceObjects as their source, and a different mix or better a new version of the performance is created. A remix that is created from more than one source is a rare case and usually referred to as a Mash-Up.

So, we should use ../PerformanceObject as source for remix. Otherwise, you will have the problem, that you have to decide which ../MasterObject to use (it's common that there are more than one for one ../PerformanceObject). So we wouldn't fix the "Always link to oldest release" problem.

Normal remixes can be stored without further change to the object chain, which contains inclusions only (i.e.o--> means (1)--(1-n)), and looks like this (Note that we are talking about instances of objects here):

OrigComposition o--> OrigPerformance o--> OrigMix o--> OrigMaster
                           o
                           |
                           V
                        Re-Mix o--> RemixMaster

To store Mash-ups we would either need to allow a ../PerformanceObject(1-n)--(1-n))../MixObject relationship, or relate performances with AdvancedRelationships. the latter would give us:

OrigComposition1 o--> OrigPerformance1 o--> OrigMix1 o--> OrigMaster1
                          ^
                          | AR: is a remix of
                          |
MashUpComposition o-> MashUpPerformance o-> MashUpMix o-> MashUpMaster
                          |
                          | AR: is a remix of
                          V
OrigComposition2 o--> OrigPerformance2 o--> OrigMix2 o--> OrigMaster2

The above means that we can create a new ../CompositionObject for a remix, if we want to (e.g. because the change was so large and 'artistic' that the result should have a composition of its own). The resulting relationships look like this:

OrigComposition o--> OrigPerformance o--> OrigMix o--> OrigMaster
                           ^
                           | AR: is a remix of
                           |
RemixComposition o--> RemixPerformance o--> Re-Mix o--> RemixMaster

Where to relate the Artist

In the ObjectModel only the ../PerformanceObject and the ../TrackObject are related to artists (how exactly we do not know yet). That means that a remix can be represented as a performance done by the remixer, that combines audio material from different original performances. The original performers are not related to the performance representing the remix, but only to the performances that the remixis based on. Uh that was a complicated sentence. Basically we have a concatenation of ../PerformanceObjects done through AdvancedRelationships as described above.

 OrigArtist(s)        RemixingArtist
      |                     |
      |          AR         |
OrigPerformance------RemixPerformance

The performing or remixing artists are all related to their appropriate level of performance. No confusion here.

At the end of this chain, we have a ../TrackObject. This is the point where things get confused, but this has nothing to do with the way we represent remixes. The confusion comes from the ../TrackObject!

People expect the properties of a track (the TrackTitle and the displayed TrackArtist) to document in a condensed form what we have ripped into pieces with the ObjectModel. There probably is no simple way to condense this information, but this is not a problem of this way of representing remixes.