otsob / wmn4j Goto Github PK

In order to write attributes (composer name etc) into MusicXML output,
as a user,
I want there to be support for writings the attributes into a MusicXML file.

Acceptance criteria:

• The composition title defined in a Score is written into a MusicXML file
• The movement title defined in a Score is written into a MusicXML file
• The composer name defined in a Score is written into a MusicXML file
• The composition arranger defined in a Score is written into a MusicXML file
• The full name of each part in the Score is written into a MusicXML file
• The abbreviated name of each part in the Score is written into a MusicXML file

In order to handle different file types through the same interface,
as a user,
I want there to be a common interface for all file reading objects

Acceptance criteria:

• There is a common file reader interface
• MusicXML readers implement the interface

In order to have clear packaging in the project,
as a contributor,
I want the package structure to follow standard format and packages to be documented.

Acceptance criteria:

• Packaging in wmn4j follows standard Java package naming (https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html)
• Each package is documented using Javadoc
• Test package naming is updated to correspond to new packaging
• Javadoc is updated so that Javadoc contains the new package naming and package documentation

Use notimestamp=true in maven-javadoc-plugin, so the updating of the Javadoc can be automated at some point.

In order to find repeated patterns in scores,
as a user,
I want there to be an implementation of the SIATECHF algorithm

Acceptance criteria:

• SIATECHF is implemented as defined in https://helda.helsinki.fi/bitstream/handle/10138/273479/otso_bjorklund_gradu_final.pdf?sequence=2&isAllowed=y
• All corresponding vector classes etc. are implemented (or separate issues are created for them and they are implemented before implementing SIATECHF)
• The implementation implements the pattern discovery interface

In order to be able to output monophonic musical patterns in notation,
as a user,
I want there to be an interface that can write a monophonic pattern to MusicXML.

Acceptance criteria:

• There is a way to create a Score from a monophonic pattern that can be written to a MusicXML file (or the pattern can directly be written to MusicXML).

In order to know which notation objects can be extended,
as a user,
I want there to be clear definition of this in wmn4j.

Acceptance criteria:

• All classes that are not designed for inheritance in the notation elements package are final
• All classes that are meant to be extended are replaced by interfaces and separate package private implementation classes

In order to write notation into MusicXML files,
as a user,
I want wmn4j to support writing basic notation into MusicXML files.

Acceptance criteria:

• Score objects can be written into valid MusicXML files
• MusicXML output for the following is supported:
  • Notes (without articulations, they are taken care of in issues #37 and #38)
  • Rests
  • Chords in notation
  • Measures (including pickup measures)

Change the handling of null values so that

• checking of null parameters uses Objects.requireNonNull
• No method returns null, but instead returns an Optional

In order to be able to output polyphonic musical patterns in notation,
as a user,
I want there to be an interface that can write a polyphonic pattern to MusicXML.

Acceptance criteria:

• There is a way to create a Score from a polyphonic pattern that can be written to a MusicXML file (or the pattern can directly be written to MusicXML).

Configure wmnlib into a Maven project so that:

• The directory structure follows the standard Maven style
• The Maven install runs tests
• Javadocs can be updated using maven

In order to handle polyphonic musical patterns (motifs with chords, segments of polyphonic music etc.)
as a user
I want there to be an interface and implementation for handling polyphonic musical patterns

Acceptance criteria:

• The polyphonic pattern should provide at least basic equality comparisons:
  • equals
  • equals in pitch
  • equals in rhythm
  • is tranpositionally equivalent
• The pattern implementation is immutable
• There are unit tests for the pattern implementation
• There is a builder class for creating patterns

In order to handle part information,
as a user,
I want the part attributes to be available through the Part interface.

Acceptance criteria:

• The full name of the part is available through the Part interface
• The abbreviated name of the part is available through the Part interface

In order to read attributes (composer name etc) from MusicXML input,
as a user,
I want there to be support for reading the attributes from a MusicXML file.

Acceptance criteria:

• The composition title can be read from MusicXML and filled into the returned score object
• The composer field can be read from MusicXML and filled into the returned score object
• The arranger field can be read from MusicXML and filled into the returned score object
• Each part in the returned score object has the full part name read from the MusicXML input
• Each part in the returned score object has the abbreviated part name read from the MusicXML input

In order to create Measure instances easily in code,
as a user,
I want to MeasureBuilder class to have sufficient functionality.

Acceptance criteria:

• There is a way to directly use a previous instance of MeasureAttributes in a MeasureBuilder instead of filling in all fields separately
• When creating a measure without all voices full, they are padded with rests at the end
• If a MeasureBuilder is filled so that it contains more elements than the time signature allows this is handled somehow by trimming or throwing an exception.
• The above functionality must also support creating pickup measures where the total duration of notation elements does not fill a measure with the specified time signature.

Define locale in maven-javadoc-plugin. Otherwise the output from "mvn javadoc:javadoc" depends on the system it is run on.

In order to handle notes with multinote articulations correctly,
as a user,
I want the relevant methods in Note to handle multinote articulations.

Acceptance criteria:

• MultiNoteArticulations and ties effect the equality of Note instances
• MultiNoteArticulations and ties effect the hashCode of Note instances

Note: Issue #29 needs to be implemented before this.

In order to ensure validity of inputted MusicXML files
as a user
I want MusicXML input to be validated against the MusicXML schema/dtd.

Acceptance criteria:

• MusicXML input in MusicXMLReader is validated
• There is also the option to not validate the input

In order to read single note articulations from MusicXML files,
as a user,
I want the MusicXML input to read articulations from the input.

Acceptance criteria:

• Staccato articulations can be read
• Tenuto articulations can be read
• Accent articulations can be read

In order to make the use of wmn4j easy,
as a user,
I want the method naming in wmn4j to follow unified conventions.

Acceptance criteria:

• Methods that return boolean start with is or similar
• All getters start with get
• All setters start with set
• Method names preferably start with a verb that describes what the method does. This is not a strict rule that every method name should follow.
• Abbreviations are not used without very good reason

In order to analyse keys,
as a user,
I want there to be an implementation of the Krumhansl-Schmuckler algorithm

Acceptance criteria:

• There is an implementation of Krumhansl-Schmuckler algorithm
• The implementation implements the general key analyser interface

In order to handle Pitch instances more efficiently,
as a user,
I want the Pitch number computation to be improved

Acceptance criteria:

• The Pitch.Base enum contains the pitch class numbers

In order to handle pitch class profiles,
as a user,
I want there to be an implementation/interface for pitch class profiles

Acceptance criteria:

• There is an interface/implementation for pitch class profiles
• There is a way to compute the pitch class profile for a collection (or an iterable) of Durationals

In order to have exceptions that clearly indicate why IO failed,
as a user,
I want informative exception types in wmn4j IO.

Acceptance criteria:

• When IO fails due to the file not found, the standard Java exception is thrown
• When IO fails due to reading MusicXML a suitable exception is thrown (should be one defined in wmn4j)

In order to make it easier to create Chord instances in code,
as a user,
I want ChordBuilder to have enough functionality.

Acceptance criteria:

• When ChordBuilder instances are created from NoteBuilder instances the fields are copied to avoid side effects
• There is a method for removing NoteBuilders from a ChordBuilder (similar to removeIf in Java Collections)
• The NoteBuilders contained in a ChordBuilder can be iterated
• There is a method for setting the duration of a ChordBuilder
• There are unit tests for all non-trivial methods in ChordBuilder

In order to keep the code quality of wmn4j high,
as the product owner,
I want static analysis to be run on the pull requests.

Acceptance criteria:

• There is a static analyser (e.g., FindBugs) that checks for at least some of the simplest bugs and fails the pull request if there are bugs.

In order to keep code quality high,
as a collaborator,
I want MusicXmlReaderDom code to be refactored.

Acceptance criteria:

• General XML document handling methods are in a separate helper class
• There are no warnings in the code
• File paths are handled using Path instead of String
• There are unit tests for reading a score builder from file

In order to write markings into MusicXML
as a user
I want MusicXML output to correctly add markings to output files

Acceptance criteria:

• Slur markings can be written
• Glissando markings can be written

In order to find repeated patterns in scores,
as a user,
I want there to be an interface for finding repeated patterns in scores

Acceptance criteria:

• The interface provides a method that returns a collection of repeated patterns and their occurrences
• If a class or interface for representing the patterns along with their occurrences is needed, it should be implemented as a part of this issue

In order to have consistent code style,
as a contributor,
I want code style defined and enforced by checkstyle on pull requests.

Acceptance criteria:

• The README includes a section on code formatting and style in general.
• A style checker checks that the code in pull requests conforms to coding style.
• There is a formatter settings file at least for Eclipse
• All errors in the codebase due to code style violations are fixed

In order to access the key signature information for keys,
as a user,
I want the interface/class for Keys to provide access to key signatures.

Acceptance criteria:

• There is a way to get the key signature for the standard major and minor keys

In order to handle different pitched notation objects,
as a user,
I want there to be a common interface for notation objects that have single defined pitch.

Acceptance criteria:

• There is an interface for pitched objects (e.g. Pitched)
• All classes that have pitch implenent the interface

In order to analyse the key of a selection of music,
as a user,
I want there to be an interface for analysing keys.

Acceptance criteria:

• The interface offers a method that takes in a collection of note objects and returns the key

In order to read multinote markings from MusicXML
as a user
I want MusicXML reading to correctly add multinote markings to Scores

Acceptance criteria:

• Legato markings can be read
• Glissando markings can be read

In order to keep API documentation easily up-to-date,
as a collaborator/developer,
I want Javadoc generation and deployment to be automated.

Acceptance criteria:

• Running local builds (i.e. mvn install) does not cause there to be changes in the contents of the docs directory.
• Javadocs are created and deployed on Github pages when a pull request is merged.
• README is updated to describe how documentation updates are handled.

In order to handle attributes of a score,
as a user,
I want the Score class to contain the attributes.

Acceptance criteria:

• The title of the composition is available in Score objects
• The subtitle of the composition is available in Score objects
• The composer of the composition is available in Score objects
• The arranger of the composition is available in Score objects

In order to read MusicXML files into Score objects,
as a user,
I want wmn4j to support reading MusicXML files to Score objects.

Acceptance criteria:

• MusicXML files can be read to Score and ScoreBuilder objects
• MusicXML input needs to be able to read all aspects of notation that wmn4j supports in v0.1, at least:
  • Notes
  • Rests
  • Chords in notation
  • Measures (including pickup measures)

In order to avoid simple bugs in code,
as a developer/collaborator,
I want checkstyle to check for simple bugs.

Acceptance criteria:

• Checkstyle checks for potential bugs (the ones it can check) in addition to style.

Potential checks to add:

• EqualsAvoidNullCheck
• EqualsHashCodeCheck
• FinalLocalVariableCheck
• IllegalInstantiationCheck
• LocalFinalVariableNameCheck
• MultipleStringLiteralsCheck
• OneStatementPerLineCheck
• ParameterAssignmentCheck
• StringLiteralEqualityCheck

In order to have information on the progress or failure of IO operations,
as a user,
I want wmn4j to log IO of files such as MusicXML.

Acceptance criteria:

• There is a logger interface that is used for logging messages in IO operations (wmn4j code doesn't print to System.out directly).
• The logger can be configured to write to System.out or to file
• The logger can be implemented using an existing open source logger if it is wrapped in an interface to decouple it from the rest of wmn4j code
• The logger is thread-safe

I order to avoid bugs in wmn4j code,
as a contributor,
I want unit tests to be run on pull requests.

Acceptance criteria:

• Unit tests are run on pull requests (e.g. using Travis).

In order to handle monophonic musical patterns (motifs, segments of melodies, melodies etc.)
as a user
I want there to be an interface and implementation for handling polyphonic musical patterns

Acceptance criteria:

• The monophonic pattern should provide at least basic equality comparisons:
  • equals
  • equals in pitch
  • equals in durations
  • is tranpositionally equivalent
• The pattern implementation is immutable
• There are unit tests for the pattern implementation
• There is a builder class for creating patterns

In order to be able to use newer Java features,
as a collaborator,
I want wmn4j to use a newer Java version than Java 8.

Acceptance criteria:

• Java version in pom is changed to a newer version (11 if there are no major backward compatibility issues with wmn4j being used in projects that use Java 8 or newer).

In order to find where a pattern occurs in a score,
as a user,
I want a way to link/mark pattern occurrences in a score.

Acceptance criteria:

• There is an interface/class for handling pattern occurrences

In order to write single note articulations into MusicXML files,
as a user,
I want the MusicXML output to write articulations into output files

Acceptance criteria:

• Staccato articulations can be written
• Tenuto articulations can be written
• Accent articulations can be written

In order to handle articulations that affect multiple notes (legato, glissando),
as a user,
I want there to be an interface/class for handling multinote articulations.

Acceptance criteria:

• There is a class or interface that represents multinote articulations
• There is a way to access multinote articulations through notation objects
• NoteBuilder has functionality for adding multi note articulations.
• MultiNoteArticulations and ties affect the equality of Note instances
• MultiNoteArticulations and ties affect the hashCode of Note instances

In order to have code that compiles with newer versions of Java,
as a collaborator/developer,
I want all usages of JavaFX.Pair to be replaces with something else.

Acceptance criteria:

• javaFX.Pair is not used in the code, but is replaced with either a custom class or something that's not deprecated.

In order to use or collaborate to wmn4j,
as a user/collaborator,
I want there to be a descriptive README.

Acceptance criteria:

• There is a section on the purpose of the project
• There is an overview of the structure of the project
• There is a link to API documentation
• There is is a section on building the project
• There is a section on how to contribute to the project
• There is a code of conduct

In order to have clear package structure,
as a user,
I want all iterators that iterate over notation objects to be placed in the same package

Acceptance criteria:

• All iterators are defined in the iterators package (as interfaces or concrete classes, implementations can be in other packages)
• All iterators implement the standard Java Iterator interface

In order to handle articulations that affect a single note in notation,
as a user,
I want the articulation markings to be available in Note objects.

Acceptance criteria:

• Notation objects provide a way to access articulations, and the following are supported:
  • Staccato
  • Tenuto
  • Accent

Note: This might require practically no further work.

In order to contribute to wmn4j,
as a contributor,
I want there to be clear code style guidelines.

Acceptance criteria:

• The README includes a section on code formatting and style in general.