History:Object Model/Representing Remixes
Thoughts on Representing Remixes in the ObjectModel
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 ../PerformanceObject
What gets remixed?
A remix doesn't combine different ../MasterObject
s. Only bootleg remixes are based on masters. The majority of proper remixes use one or more ../PerformanceObject
s 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.
(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
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 ../PerformanceObject
s 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.
- To be precise, it is a tree and has several ends, but they all are ../TrackObject