Notes

Meeting with Steve Larson on Saturday, May 29

Discussion

• Discussion of my SeekWell Single-Level Model implementation
  • The model's input and output should be in the same form (instead of current one-way conversion to integer representation)
  • Make sure the special cases are correct for picking the one or two notes to use in the prediction.
  • Alphabet selection should be done after removing the final note due to a leap-to-unstable
  • Alphabet selection is different for inertia predictions than for gravity/magnetism predictions. An inertia prediction should choose a reference alphabet such that the final two notes used in the prediction are adjacent in that reference alphabet. If the notes are moving by step, for instance, a diatonic reference alphabet might be chosen, but it they move by leap a major triad reference level might be used instead. Thus, here inertia is defined as moving in the same way -- where the "same way" means moving "in the same direction in the same reference alphabet until reaching a goal pitch".
  • Even if only one note is in the cue, predictions should still be generated. (give the example where this does not occur)
  • Examples:
    • (predict '(C D B)): inertia prediction should not occur because this is not motion through adjacent members of any reference alphabet.
    • (predict '(C F E)): the inertia prediction needs to use a different reference alphabet than the other types: they only choose major-triad, while inertia has the major scale available.
    • (predict '(D E A)): we need to remove the final note before picking the alphabet due to leap-to-unstable..(?).
    • (predict '(C D G)): the reference alphabet should include D but the goal alphabet should not include G...(?)
• GUI implementation notes
  • Next implementation goal is to develop a single-level implementation with a graphical interface.
  • Three panels:
    • Input:
      • includes a Key selection (C, C#, Db, D, etc...) -- without the mode
      • Staff display, without key signature. Enharmonic choices are displayed as two noteheads with one stem, and both accidentals visible
      • Keyboard graphic for input
      • Backspace or other editing buttons for changing the input
      • File|Save,Open for storing cues
      • Option buttons for features such as
        • recursive predictions (these must terminate when reaching a tonic)
        • the ability to do an inertia prediction even when the final note is a goal pitch
        • if magnetism results in a tie, choose to use both predictions or neither
      • Means to edit the weight parameters to be used in predictions
    • Output
      • Staff display with key signature, proper music notation (satisfy the goal that user input and model output are as similar as possible)
      • All major continuations are listed (in a scrolling window if necessary?)
      • Scores and probabilities for each continuation are displayes
    • Working
      • Key decisions are displayed such as the trimming of the final note due to a leap-to-unstable
      • Perhaps the 1 or 2 notes used in the prediction should be displayed
      • The reference/goal alphabet pairs used for each prediction type (1.inertia 2.magnetism/gravity)
  • The next version will handle the multi-level model, so consider this during design. Specifically, input will need to include the Schenkerian analysis.
  • Consider developing as an ASP.NET application to solve Win/Mac compatibility issue.
  • Along the same lines, be careful to separate client display from internals, becuase I'm interested in both ASP.NET and Windows Forms versions
• Need to write technical reports:
  • Discussion of 2 SeekWell examples
  • T561 report improvement
    • Read more on key determination, including David Butler vs. Krums..
      • Note how we tend to quickly pick a key; we her music in just one key; we don't maintain several keys at once... Then it is difficult for us to change
      • We similarly get entrained in a particular meter, and it takes special events to displace the perceived beats.
    • Incorrect statement in my report about metric restriction of the embellishment hierarchy as a restriction on the SeekWell domain; it's just a restiction of the internal analysis
    • Consider: is a structure-finder really necessary, or does "Describing an embellishment note" automatically include this?
    • Note the need for an internal representation of found lines in a compound melody, where lines have been compressed into chords (reverse of Westergaard procedure from combining two species lines)
    • The start of article is like "Seek Well: A Creatie Microdomain for Studying Expressive Meaning in Music"
    • Clarify terminology: note how Narmour "redefines" the term "bottom-up" to mean "learned through experience" or "extra-opus" in contrast to the more usual definition.
    • Response to Dr. Isaacon's question: something like a "slipnet" should dynamically decide which level will prevail in a conflict. It will probably be middle-ground instead of background, however.
    • Compound melody: recognized by "steps, leaps, and a consistency in treating them"
    • Pg. 20: be more positive!
• Need to think about how to come up with a score for any prediction, including recursive predictions. In general, a score whould be based on how well the different levels of an analysis give in to musical forces. Consider an examples like G A G - E F E - C D C.
• Email Dr. Larson if I have any questions about Westergaard

TODO List:

1. Ask Dr. Larson to send a copy of "Step by Step"
2. A techincal report describing how we hear two or three examples in the SeekWell domain, based on those examples we looked at earlier this year. (Perhaps this report would be similar in style to "Step by Step"?)
3. A single-level model implementation that corrects the issues you pointed out in my current version as well as adding the visual interface.
4. A technical report involving the implementation ideas discussed in my paper for Dr. Isaacon's class as well as musical examples.
5. Continuing to work through Westergaard.

Detailed TODO:

Technical Report 1

1. Outline 1st technical report
2. Write introduction/background material
3. Write 1st musical example
4. Pick and write 2nd example
5. Do a 3rd example if appropriate
6. Complete writing

Single-Level Model

1. Pick client platform: Windows Forms or ASP.NET? Consider which music font to use and how it works on each platform.
   1. Chose ASP.NET (with desire for making parallel versions as time permits)
   2. Music staff display will simply be a rendered image, drawn as an HTML <img> in ASP.NET
   3. I registered seekwell.org and set it up for ASP.NET hosting
   4. Note: To do animations later on, I can just do automatic page refreshes of the changing elements; these can be displayed in frames to avoid redrawing the entire screen.
2. Complete a Staff control for the chosen platform (preferably it would work on either platform...), incorporating options for key signatures, enharmonic note display, and "smart" accidental display based on key signature (optional). No barlines necessary, horizontal spacing determined only by # of accidentals. Only support filled or open noteheads, monophonic, auto stem-direction, option to turn off stems on select notes. The Staff control could have an added "play" button that would generate and play a MIDI file of its contents.
3. Create a keyboard input control for the chosen platform (or both if it's easy).
4. Create dummy app with visual elements.
5. Choose internal data structure
6. Port Scheme version of model to C#, correcting existing problems.
7. Implement remaining interface elements.