User Tools

Site Tools


recordedmusic

Recorded Music

Ideally this page should be a large table, with columns that can be reordered and resorted and searched by the user. It should allow for extensions. How to do this is a challenge, but one I (NashJc) am prepared to attempt. Thus at first, t

For information, the Ottawa Club has a mostly up-to-date spreadsheet of dance music, but the column entries are not all complete.

Access to the data (user interface)

Want a fairly simple table structure that lets users see a table and edit it.

  • Must have a selector mechanism
  • “Edit item”
  • Save back
  • Revert?

Would be nice to be able to load data in bulk, but this is likely quite difficult.

Would also be useful to be able to flag when fields are empty.

Possibilities

We could try to use a database (see below), or use the Mediawiki sortable tables

20090330: Let us try to set up a table for CDs (??other recordings?) as CD_Table

Desirable fields in a dance music database

Note that there are already CD databases. These were examined for suitability, but lack the information dancers need. This does not mean that they may not be useful. If you know how, let us know!

Table for recordings (album)

  • albID: automatically assigned album ID (for this system)
  • Performer: Artist or Group (cannot be null)
  • Name of recording / CD (cannot be null). Drop “A” or “The” at the beginning of the names.
  • Date of issue (How should we handle re-issues)
  • Short name or RecordingIdentifier (possibly could drop this, but it might be very useful for display purposes)
  • Format – Do we want to have one row of entry for each format? In this case, we should have an entry that has an indication that there are multiple formats, then one can look for other “rows”. This is a set cd, cas, lp33
  • Publisher

Table for tracks

  • TrackID: autoincremented internal track identifier
  • DanceName: Name of dance – This could be generic e.g., 32 bar reel, but it would be nice to be able to indicate which dances are specific and which are generic. Also we may want to indicate alternative dances, but clearly this makes for very lar
  • Generic: N/Y/S for No, Yes, Sometimes, that is, a tune that can be linked to a specific dance but can also be used generically.
  • TuneType: jig, reel, etc. See types in database structure. May want to expand.
  • TuneNames: Names of tunes if different than “for named dance”
  • Duration: Timing (in seconds? – generally given as mins:seconds, but it would be good to standardize)
  • Rounds: Number of rounds
  • BarCount: bar count
  • Comments (too slow, too fast, too …)
  • TrackSeq: track sequence number (sequence number, side/number). Note that with CDs it is track number, with tapes, Side:Number, which may be more than A/B in case of multiple cassettes.
  • (Optional) FileName: File name if converted. ?? Do we need path information, or can we develop a good filename format? Currently, legacy material has been influenced by MS-DOS 8:3 format, and even modern operating systems have length and sometime

Table for dances

  • danceID: internal identifier. May be more than one row of this table for a given dance name, but album and track should be unique.
  • DanceName: Name of dance (for consistency, should match the name in the Dance Instructions, i.e., no quotes etc.
  • DanceVersion: to allow for different forms, This can be a, b, c, …
  • albID: Album identifier
  • TrackID: Track Identifier
  • DanceFormation: dance formation and/or number of dancers e.g., Longways for as many as will – can we encode this sensibly?
  • numunits: number of couples or dancers or trios
  • unitdancers: Set of 'couples','dancers','trios'
  • AlternateFormations ?? may be simpler to put in as separate entry for different formation
  • Instructions: link to Playford site page(s) ??
  • ExtLink: URLs for external stuff ??
recordedmusic.txt · Last modified: 2014/07/15 21:52 (external edit)