We are now including a tutorial as a part of the documentation. The purpose of this is to quickly orient the user with RobotRock. The tutorial will reveal the key aspects of RobotRock and how to use them (ex. how to add an instrument, the effect of moving an instrument around, how to pause the music, etc).
We are also adding a User Help documentation, available online: UserDoc.
The user interface has been simplified to create less clutter and to emphasize the core attributes of RobotRock. For example, the band order is hidden, as well as key, tempo, and time signature, as "advanced features."
Musician widgets are simplified with a minimum number of buttons on them. This makes the widgets simpler to setup and also decreases the likelihood that a user will click on a button they did not mean to or suffer confusion from a plethora of widgets.
Musician widgets no longer resize since this system did not seem to be intuitive or helpful in user tests.
No two musicians widgets can occupy the same space on the canvas. This makes the musicians easier to view.
The beta release has been moved to be a week earlier then previously anticipated due to changes in the class schedule.
The GUI now maintains a reference to the instantiated musician objects. This change occurred because previously the GUI instantiated the musicians and would later access them through the CoreController interface. Rather than querying the system for the objects, we decided to let the GUI use existing references.
Most of the GUI's widgets are now defined by types sub-classed from Qt's base widgets.
The musicians are no longer responsible for maintaining their position within the score, but rather have the conductor specify the measure and the window-of-opportunity in which to write. This design choice was two-fold: first, the designers of the musicians are no longer responsible for this bookkeeping; second, the possibility of musicians becoming out of sync each other is removed.
The conductor serves as a useful central point of control for writing to the score, which helps reduce redundancy and simplify the flow of control. The conductor naturally assumes responsibility for updating measure meta-data before it is received by musicians and directing newly added musicians to their proper place in the score.
The current implementation of the metronome and parser operate on the concept of "atomic beats" (see AtomicMetronome.py and AtomicParser.py). This model places some constraints within the system which modules can assume, specifically that the system will update itself in small, fixed intervals. These choices sped up the production of code that met our audio and response requirements at the expense of processing overhead and loss of precise note resolution.
The parser was supplemented with the notion of a Receiver class. This class is responsible for processing the events from the parser, either by generating audio or capturing debugging information (see fsreceiver.py and testatomicparser.py).
A class was added, for the sake of the parser, to obtain note data relative to a marker within the score (see scoremarker.py). It interacts closely with scoreslice.py to retrieve all the measures from a vertical window segment of the score.
For ease of musician design, several utilities modules were added. These files assist in obtaining relative tones (tones.py) and constants for note dynamics (see dynamics.py). Furthermore, a new sub-class of Musician was added to provide another view for creating musicians (see musicianstructured.py).
click here to view source
The class ExpandingList uses the following design patterns:
list object (a python builtin). It overrides the accessor method __getitem()__ such that it is not possible to return a null reference from a positive index access call.__default_object()) to build list elements when the list superclass requires expansion. Since the elements are built using only a dictionary and/or arbitrary parameter lists, the factory function is generic for any type of class. In this way, we use the Builder pattern, since the same construction process can create completely different class representations.__getitem__().