History:Performance Restructuring Proposal

Status: This page describes an active proposal and is not official.

Proposal number: RFC-37 Champion: BrianFreud, was Shepard Current status: In development

This page is about restructuring AdvancedRelationshipTypes and AdvancedRelationshipAttributes connected to the PerformanceRelationshipClass and the types in MusicalAssociationRelationshipClass which use the VocalRelationshipAttribute or the InstrumentRelationshipAttribute or any that is proposed here.

Because I found different unrelated problems which can be implemented / solved uneffecting the others I structure this into sections.

Speech

Speech is completly different from vocal performance which is intended to be singing, rapping or doing recitate and the like. Therefore I propose to add a sub-type SpeakerRelationshipType to the vocal PerformerRelationshipType and NarratorRelationshipType, ReaderRelationshipType as subtypes to SpeakerRelationshipType.

For details see named types and PerformanceRelationshipClass.

Redesign of the Vocal Relationship Attribute

Note: The AdvancedVocalTree is a more detailed version for how to implement this.

Separating vocal role, vocal range/tone and vocal style

Currently it is not possible to define vocal ranges for background singers or choirs. Is this necessary? If so it would probably be better to split this into two attributes vocal role and vocal range.

Adding vocal styles

Vocal styles can be added to the "The Tree" at the AdvancedVocalTree page.

Do we need vocal styles at all? Examples: Rap, Recitative/Sprechgesang, Death Growl. Discus at AdvancedVocalTree.

Adding Attribute "Performance Role"

Currently it is not possible to have text-field attributes in AdvancedRelationships (apart from the dates). A proposal for this is on AdvancedRelationshipsFreeTextQualifiers, 1142 keeps track of it.

It would be nice to be able to define a role for a performance though as free-text. That is: a (fictional) character that is represented by an instrument, a singer or a speaker.

That would look like this:

performed {additional} {guest} {instrument} (as {role}) on
performed {additional} {guest} {vocal} vocal (as {role}) on
 {additional:additionally} {guest} spoke (as {role}) on

Examples:

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

Kent Broadhurst spoke as The Hypnotherapist on Regression

This could be useful for musicals, operas, metal operas and so on.

Adding Sub-Types to Band Members

The SupportingMusicianRelationshipType in the MusicalAssociationRelationshipClass was implemented with sub-types to specify instruments or vocals of the support. The MemberOfBandRelationshipType does not yet have that.

One proposal was to have something like this:

is/was a member of
 played {instrument} in
 performed {vocal} vocal in

• This would mean, a lot of members had to be linked twice. Can't this be grouped in 1 AR somehow? --Fuchs
  • Well, you would not use the sub-types _and_ the MemberOfBandRelationshipType but use it instead of. the first sub-type can hold multiple instruments. But I see no possibility to combine vocals and instruments in one AR type. --Shepard

---

Allow Instrument Attribute for Members of a Band

Should MemberOfBandRelationshipType not have an instrument attribute? --DonRedman

This would introduce some additional complexity in interpreting artist roles: see ArtistRoleInheritance --MatthewExon

Another thought: the instrument attribute doesn't have "vocals", so this wouldn't work for recording singers. Maybe the InstrumentRelationshipAttribute hierarchy should include the VocalRelationshipAttribute hierarchy, and "Performed instrument on" be merged with "Performed vocal on"? There are other roles for members of a band as well: The Prodigy has two dancers as "official" members. IMO these could probably be adequately covered by "other" --MatthewExon