Building Silverlight Chord Factory: Part 1 – The Data Model

Back in November 2008 I posted about converting my reference app Chord Factory to Silverlight – Chord Factory is a piano chord finder utility that I wrote years ago and I have been porting from one development platform to the next as a series of protracted learning exercises ever since. It started out as a VB6 WinForms app and has been through various .NET incarnations since. The Silverlight version went through partially complete Silverlight 2.0 and 3.0 versions in a fairly monolithic architecture and I always meant to produce a few posts about the code once I had it complete and had a published version on my website.
But before I had managed that (see the most recent incomplete version here) I became interested in overhauling the component design and re-architecting it as another learning exercise, this time to help me work through the concepts of producing loosely-coupled component designs using MVC/MVVM patterns and looking at concerns like unit testing & testability together with an attempt at expressing the data structures involved in XML.
I long since gave up trying to make the UI pretty – whilst I think I can distinguish good UI/UX from bad I am no designer, but I have managed to produce something that fits some of the MVVM principles and allowed me to understand how MVVM works and makes for testable components and clean data-binding. And before I get distracted again and feel the urge to overhaul the code again and douse everything in MEF, it is time for those long-delayed posts.

Representing note sequences as data

Without straying too much into music theory, chords and musical scales are basically sequences of notes – the 8 notes in a scale (e.g. the scale of C Major: C-D-E-F-G-A-B-C) or the 3, 4 or more notes in a chord (e.g. the chord of C Major: C-E-G) can be stored and positions or offsets in a sequence. However the progressive sequence is measured in pitch-steps of semitones from the starting note i.e. including the black notes (looking at the piano keyboard, the semitone sequence starting from the note C is: C, C#, D, Eb, E, F, F#, G, Ab, A, B, C, C#, D, Eb… and so on up the keyboard). So to store the sequence for the scale of C Major we need to store offsets for the 1st, 3rd, 5th, 6th, 8th, 10th, 11th and 12th semitones, and for the chord of C Major we need to store the offsets for the 1st, 5th and 7th. With this information for a scale or a chord we have the means to select or highlight on the UI representation of our piano keyboard the notes that make it up, starting at the base or root note – C in the previous examples.
We can now store these sequences of offsets for all the standard scales and chords that musicians have come up with and use them to produce representations of any variation from a particular root note. An XML schema for these sequences is simple to produce: 

CHORD DATA SCHEMA

1. <?xml version="1.0" encoding="utf-8"?>
2. <xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd"
3.            elementFormDefault="qualified"
4.            xmlns="http://tempuri.org/XMLSchema.xsd"
5.            xmlns:mstns="http://tempuri.org/XMLSchema.xsd"
6.            xmlns:xs="http://www.w3.org/2001/XMLSchema">
7.   <xs:element name="ChordFactoryData">
8.     <xs:complexType>
9.       <xs:sequence>
10.         <xs:element name="Chords" type="Chords" />
11.         <xs:element name="Scales" type="Scales" />
12.       </xs:sequence>
13.     </xs:complexType>
14.   </xs:element>
15.   <xs:complexType name="Chords">
16.     <xs:sequence>
17.       <xs:element name="Chord" minOccurs="1" maxOccurs="unbounded" type="NoteSequence" />
18.     </xs:sequence>
19.   </xs:complexType>
20.   <xs:complexType name="Scales">
21.     <xs:sequence>
22.       <xs:element name="Scale" minOccurs="1" maxOccurs="unbounded" type="NoteSequence" />
23.     </xs:sequence>
24.   </xs:complexType>
25.   <xs:complexType name="NoteSequence">
26.     <xs:sequence>
27.       <xs:element name="SequenceType" type="SequenceType" maxOccurs="1" minOccurs="1" />
28.       <xs:element name="Description" type="xs:string" maxOccurs="1" minOccurs="1" />
29.       <xs:element name="NoteList" type="NoteList" maxOccurs="1" minOccurs="1" />
30.     </xs:sequence>
31.   </xs:complexType>
32.   <xs:complexType name="NoteList">
33.     <xs:sequence>
34.       <xs:element name="NoteIndex" type="xs:int" minOccurs="1" maxOccurs="unbounded" />
35.     </xs:sequence>
36.   </xs:complexType>
37.   <xs:simpleType name="SequenceType">
38.     <xs:restriction base="xs:string">
39.       <xs:enumeration value="Chord" />
40.       <xs:enumeration value="Scale" />
41.     </xs:restriction>
42.   </xs:simpleType>
43. </xs:schema>

 

The XML for a Major Chord would then look like this:

MAJOR CHORD

1. <chords>
2.   <chord>
3.     <sequencetype>Chord</sequencetype>
4.     <description>Major</description>
5.     <notelist>
6.       <noteindex>0</noteindex>
7.       <noteindex>4</noteindex>
8.       <noteindex>7</noteindex>
9.     </notelist>
10.   </chord>
11.  
12.   ...more chords...
13.  
14. </chords>

 

and a Major Scale would look like this:

MAJOR SCALE

1. <scales>
2.   <scale>
3.     <sequencetype>Scale</sequencetype>
4.     <description>Major</description>
5.     <notelist>
6.       <noteindex>0</noteindex>
7.       <noteindex>2</noteindex>
8.       <noteindex>4</noteindex>
9.       <noteindex>5</noteindex>
10.       <noteindex>7</noteindex>
11.       <noteindex>9</noteindex>
12.       <noteindex>11</noteindex>
13.       <noteindex>12</noteindex>
14.     </notelist>
15.   </scale>
16.  
17.   ...more scales...
18.  
19. </scales>

 

Data Classes

In my MVVM implementation this Chord and Scale data is loaded into models that represent the Chord or the Scale and I can then produce collections of instances of all the Chords and Scales. Here are the simple models in C#:

DATA MODEL CLASSES

1. public abstract class NoteSequence
2. {
3.     public List<int> Notes { get; set; }
4.     public string Description { get; set; }
5. }
6.  
7. public class Chord : NoteSequence
8. {
9.     public static Chord CreateNewChord()
10.     {
11.         return new Chord();
12.     }
13.  
14.     public static Chord CreateChord(string description, List<int> notes)
15.     {
16.         return new Chord
17.         {
18.             Notes = notes,
19.             Description = description
20.         };
21.     }
22.  
23.     protected Chord() { }
24. }
25.  
26. public class Scale : NoteSequence
27. {
28.     public static Scale CreateNewScale()
29.     {
30.         return new Scale();
31.     }
32.  
33.     public static Scale CreateScale(string description, List<int> notes)
34.     {
35.         return new Scale
36.         {
37.             Notes = notes,
38.             Description = description
39.         };
40.     }
41.  
42.     protected Scale() { }
43. }

In implementation, the Chord and Scale classes are no different and it could be argued that the respective data could be loaded into two collections of the more general NoteSequence class (which would have to be changed from its current abstract incarnation of course); but I prefer to keep them as separate classes as they are logically different and might diverge in the future.

So I now represent my chord and scale data as XML and I have a straightforward model for instantiating it in data objects. The next stage is to load that data into a ViewModel using data access code that will deserialize the XML into the objects. That will be in part 2.