Robot Rock Beta

Notes

• See the ticket database here for known bugs.
• testsoundfontdirectory.py fails because soundfontdirectory.py is not yet implemented--this is our due to our 'tests first' development approach.
• testaddmusician.py is an integration test. So is testfsreceiver.py, since it creates actual audio as part of its test.
• Filter edit activity per user here.
• We have daily builds working, which send an email to the group list at or around 5 PM.

Developer/User Docs

• UserDoc -- for users.
• DeveloperDoc -- for developers.

Changes made to the requirements since the original SRS release

• External Documentation

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.

• User Interface

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.

• Schedule

The beta release has been moved to be a week earlier then previously anticipated due to changes in the class schedule.

Several changes in the design since the original SDS and Zero-Feature Release:

• GUI

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.

• Conductor changes

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.

• Implementation decisions

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).

• Internal class additions

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.

• Misc.

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).

Design Patterns in Robot Rock

ExpandingList.py

click here to view source

The class ExpandingList uses the following design patterns:

• Inheritance or subclassing: the class inherits fromlist 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.
• Factory method/Builder: the class uses a factory method (__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.
• Lazy initialization: this pattern is at least partially applied. No list element is instantiated until a reference to its (out-of-bounds) index is made. Once this occurs, the entire list is expanded, and all items in the list are instantiated up until the latest reference.

Python idioms:

• EBFAP: Easier to beg forgiveness than ask permission. Used to catch and handle out of bound list indices in a try/catch block for __getitem__().