History:Object Model/Representing Remixes: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
(how to represent remixes in the object model (Imported from MoinMoin)) |
(problems with that (Imported from MoinMoin)) |
||
Line 9: | Line 9: | ||
So things have becom simple again. Good sign. |
So things have becom simple again. Good sign. |
||
But there are also negative consequences: If youhave no differentiation between recording and mix and every remix becomes an own performance then you have to relate the performing artists to all of them - which was the reason again to originally build several layers. |
|||
[[Category:To Be Reviewed]] |
[[Category:To Be Reviewed]] |
Revision as of 01:31, 22 November 2005
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 from the ../MasterObject
s that get remixed to the ../PerformanceObject they get remixed in.
So things have becom simple again. Good sign.
But there are also negative consequences: If youhave no differentiation between recording and mix and every remix becomes an own performance then you have to relate the performing artists to all of them - which was the reason again to originally build several layers.