MAIDENS 1.4: Project Hierarchy as shown by the Project Structure panel

The Project Hierarchy

What Is It

While software creators commonly opine against sharing implementation details with their user base, the author of MAIDENS thinks differently. He reckons good technical rundowns drive comprehension, operational effectiveness and ultimately software adoption. In this light, you are hereby given the MAIDENS’ project data model.

What It Does

MAIDENS organizes your work in autonomous units called projects. A Project houses both musical content (e.g., sections, parts, measures) and non-musical assets (generators). Also, it follows a hierarchical, strict, consistent and homogeneous structure. Some members in this hierarchy are recipients that can be populated, some are end-points where actual content or functionality hooks in, and some are neither (they exist just for grouping purposes).

Implementation Summary

The following listing documents in brief the structure of a MAIDENS project. A dedicated section for each item is also provided.

  1. Project:
    • position & type: top-level container;
    • children: two, predefined and irremovable (of types Generators and Score);
    • editable properties: Name, Composer, Copyright, Notes.
  2. Generators:
    • position & type: level-2 container;
    • children: unlimited and removable (of type Generator);
    • editable properties: none.
  3. Generator:
    • position & type: level-3 leaf; end-point for hooking up an actual instance of a generator — more on generators and instances in their dedicated article;
    • children: none;
    • editable properties: Binding, Input connections, Output connections, Generate, Configure, Info.
  4. Score:
    • position & type: level-2 container;
    • children: unlimited and removable, one initially (of type Section);
    • editable properties: none.
  5. Section:
    • position & type: level-3 container; live node with regard to children manipulation — adding, removing or nudging a Part child in one Section propagates to all the other Sections;
    • children: unlimited and removable except last (of type Part);
    • editable properties: Name.
  6. Part:
    • position & type: level-4 container; live node with regard to editing and children manipulation — changing properties of a Part is mirrored across all Sections; adding, removing or nudging Measure children propagates to all Parts;
    • children: unlimited and removable, one initially per Section (of type Measure);
    • editable properties: Instrument, Number of staves, System bracket type, Clef(s).
  7. Measure:
    • position & type: level-5 container; live node with regard to nudging and deleting — deleting or nudging a Measure in a Part is reflected in all Parts;
    • children: up to twice the staves number of the parent Part, removable except for the last Voice of each staff (children are of type Voice);
    • editable properties: Bar Type, Time Signature.
  8. Voice:
    • position & type: level-6 container;
    • children: unlimited and removable (of type Cluster);
    • editable properties: Voice position, Voice Staff.
  9. Cluster:
    • position & type: level-7 container;
    • children: unlimited and removable (of type Note);
    • editable properties: Duration, Dot, Tuplet.
  10. Note:
    • position & type: level-8 leaf;
    • children: none;
    • editable properties: Pitch, Octave, Augmentation.

Note: the complete list of pending bugs, features and epics is available in Jira.

Search Documentation

Hint: use the browser's search feature to search within results (use Ctrl+F on Windows or  ⌘+F on macOs).