- Time signatures other than 4/4 have not been tested.
-
The way ScalePart handles chords need to be refactored. Currently, the raw data points are
first converted to notes and the duration set from addFactors.
This can result in 2 or more notes joined by a tie. For example assuming 480 base units per measure
300 units are represented by 2 notes: a half tied to an eighth.
ScorePart creates chords by picking off notes one at a time and this is complicated by
tied notes which is meaningless in a chordal context. Also handling end of the measure processing
is complicated (and currently doesn't work) with tied notes. -
ScoreAnalysis doesn't work on polyphonic instruments (viz. it doesn't parse the chord notes correctly).
For these instruments (such as PianoLFChords) set -analysis false on the command line. -
Test that MusicXMLHelper is handling chord ties correctly - both within and across bar lines.
-
ScaleExportManager. Add "musicXML" as an output format. This would consist of a 2-octave range ascending and descending
starting with the specified root note(s) for each exported scale. The resulting musicXML file could then be
imported into MuseScore to hear how the scale(s) sound. A further enhancement could add chords to scales of 8 notes or less. -
ChordManager. Add "musicXML" as an output format for
-export chords
option. This would output a musicXML
file that could be imported into notation software in order to hear what the chords sound like. -
Add MelodyCollector and MelodyProducer to cp (collector-producer) package. These will be the melody equivalents of HarmonyChordCollector and ChordProgressionProducer.
-
Add an option for including rhythmic elements in MarkovChain creation for chords & melodies.
Essentially build Markov Chains on melody/chords alone, rhythm alone (i.e. durations), and melody/rhythm, chord/rhythm.
The result could be fed into a Producer. -
Add a musicXML to/from songJSON conversion. Recall that songJSON is an alternative to musicXML that consists of musical
elements only. That is, formatting is not included. This really simplifies creating song.json files which can be
the input to Collector/Producer processing. This could be done explicitly or implicitly when providing a musicXML
file for Collector/Producer processing. -
Allow for occasional rests. There is a configuration parameter score.restProbability, given as %, but it's not currently used.
Instruments should have the ability to override this global value as in<instrument_name>.restProbability
For exampleFlute.restProbability=15
-
Add a help option (-h or --help) to the following programs: ChordManager, ChordProgressionProducer, HarmonyChordCollector,
ProductionFlow, ScaleExportManager, and also MelodyCollector and MelodyProducer when those classes are completed. -
Create a single script to import scales, chords, songs and fractal files into MongoDB. This would encapsulate the steps in Imports.md
-
Simplify the instrument properties in orchestration.properties. The
music.instrument.
andscore.instrument
prefixes can be dropped.
For example,music.instrument.Flute.instrument-sound
becomesFlute.instrument-sound
andscore.instruments.BassClarinet.class
is simplyBassClarinet.class
. Also the "vocal" for SATB parts can also be dropped
somusic.instrument.vocal.Bass.midiProgram
becomesBass.midiProgram
. -
Chord processing (ScorePart class) needs to work off it's own List separate from the List used by Monophonic instruments.
Instead of tieing notes, addList<Duration> factors
attribute to the Note.
To further simplify processing, create separate scoreInstrument() methods for Monophonic and Polyphonic instruments.
Namely, scoreInstument -> scoreMonophonicTextureInstrument() or scorePolyphonicTextureInstrument(). -
Refactor Melody, SongNote to use the NoteType enum instead of a String. NoteType encapsulates
the type of note (as in whole, half, eighth, etc.) and the number of dots (up to 3 depending on the type).