Event — Object with a property list (lazily created) DurationEvent — adds duration instance variable MusicEvent — adds pitch and voice instance variables ActionEvent — has a block that it evaluates when scheduled It is seldom necessary to extend the hierarchy of events. Examples of verbose and terse Siren event creation messages are given below. Verbose Event Creation Messages— – Class messagesMessages Create a ‘generic’ event. MusicEvent duration: 1/4 pitch: ‘c3’ ampl: ‘mf’. Create one with added properties. (MusicEvent dur: 1/4 pitch: ‘c3’) color: #green; accent: #sfz. Terse Event Creation using Using concatenation Concatenation of music Music magnitudesMagnitudes 440 Hz, (1/4 beat), 44 dB. “Simple event” 490 Hz, (1/7 beat), 56 dB, (#voice -> #flute), (#embrochure -> #tight). “with an added (arbitrary) property” (#c4 pitch, 0.21 sec, 64 velocity) voice: Voice default. “Event using different syntax” EventList objects hold onto collections of events that are tagged and sorted by their start times (represented as the duration between the start time of the event list and that of the event). The event list classes are subclasses of DurationEvent themselves. This means that event lists can behave like events and can therefore be arbitrarily deeply nested, that is, one event list can contain another as one of its events. The primary messages to which event lists respond (in addition to the behavior they inherit by being events), are (anEventList add: anEvent at: aDuration)—to add an event to the list—(anEventList play)—to play the event list on its voice (or a default one)—(anEventList edit)—to open a graphical editor in the event list—and Smalltalk-80 collection iteration and enumeration messages such as (anEventList select: [someBlock])—to select the events that satisfy the given (Boolean) function block. Event lists can map their own properties onto their events in several ways. Properties can be defined as lazy or eager, to signify whether they map themselves when created (eagerly) or when the event list is performed (lazily). This makes it easy to create several event lists that have copies of the same events and map their own properties onto the events at performance time under interactive control. Voices handle mapping of event list properties via event modifiers, as described below. In a typical hierarchical Smoke score, data structure composition is used to manage the large number of events, event generators, and event modifiers necessary to describe a full performance. The score is a