History:Performance Restructuring Proposal: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
((Imported from MoinMoin))
(discussion (Imported from MoinMoin))
Line 54: Line 54:


Now rip my proposal into pieces. :)
Now rip my proposal into pieces. :)

----


OK, here we go:

Why don't you add a sub-type "lead" to vocal performance? This way the main type would really mean: "Some vocals, but i don't know how exactly".

Also, it seems to me, some of these sub-types could also be represented by an attribute like {vocal-role} which would then be either lead, background, or choir. I think the main point you show, is that vocals should be categorized along ''two'' dimensions: {vocal-role}, meaning how the vocalist relates to the rest of the band (lead, background,...), and {kind-of-voice}, meaning the vocal "instrument" or style the vocalist uses (alto, rap,...). I would prefer having these as two independent attributes to a single [[Advanced Relationship Type|AdvancedRelationshipType]].

Finally, note that your {role} attribute is a neat idea, but currently unimplemented. There cannot be a text-field to [[Advanced Relationships|AdvancedRelationships]]. --[[User:DonRedman|DonRedman]]


----
----

Revision as of 12:03, 23 August 2005

Proposal

Tree Structure

performed {additional} {guest} {instrument} (as {role}) on
performed {additional} {guest} {vocal} vocal (as {role}) on
 performed {additional} {guest} background {vocal} (as {role}) on
 performed {additional} {guest} choir {vocal} (as {role}) on
 performed {additional} {guest} speech (as {role}) on
  {additional} {guest} narrated
  {additional} {guest} read
orchestra performance... (untouched)

Attributes

"Vocal" is selected from a drop down menu as one of the following:

 [select vocal]  (selectable if no additional vocal type is needed)
 Classical tones  (non-selectable group-item)
  Alto
  Baritone
  Bass
  Contra-tenor
  Mezzo-soprano
  Soprano
  Tenor
 Recitative
  Rap
 Some other items such as African chants

As you can see here, the vocal tones can all be just a vocal, a background vocal or a choir vocal. If this is correct for all of them I don't know. Perhaps the different ARs can have different drop down lists (choir would not make much sense for rap for example).

The attribute "Role" is set by a text field. For narration and reading this is not appropriate since both reader and narrator are outstanding persons who are just defined as having no role on a story.

Difference between reader and narrator:

A reader reads an audiobook to us (he also reads the spoken parts of characters). A narrator tells us the story but he does not speak the spoken parts of characters in the story. Either they are spoken by others (in radio plays - then "performed speech" is used for them) or he tells us what they said (re-narrate).

About the attributes "additional" and "guest" I'm not sure at the moment.

Examples

Jim Dale read Harry Potter and the Sorcerer's Stone (feat. narrator: Jim Dale) (disc 1) ("feat. narrator" is actually wrong here! It should be "feat. reader" or something)

Sting narrated Peter and the Wolf (feat. narrator Sting)

SomeName performed Oboe as The Duck on Peter and the Wolf (feat. narrator Sting)

Wallu Walpio performed speech on Introduction by Wallu Walpio

Kent Broadhurst performed speech as The Hypnotherapist on Regression

Discussion

Now rip my proposal into pieces. :)



OK, here we go:

Why don't you add a sub-type "lead" to vocal performance? This way the main type would really mean: "Some vocals, but i don't know how exactly".

Also, it seems to me, some of these sub-types could also be represented by an attribute like {vocal-role} which would then be either lead, background, or choir. I think the main point you show, is that vocals should be categorized along two dimensions: {vocal-role}, meaning how the vocalist relates to the rest of the band (lead, background,...), and {kind-of-voice}, meaning the vocal "instrument" or style the vocalist uses (alto, rap,...). I would prefer having these as two independent attributes to a single AdvancedRelationshipType.

Finally, note that your {role} attribute is a neat idea, but currently unimplemented. There cannot be a text-field to AdvancedRelationships. --DonRedman



Some category.. - Original author: Shepard