Readings

1
Readings 30 Konstantinos Meintanis Cooperative
Visual Manipulation of Music Notation

• By P. Bellini, P. Nesi and M. B. Spinu
• University of Florence, Italy
• ACM Transactions on Computer-Human Interaction
  (TOCHI), September 2002

2
Collaboration in Music

• Until now, very limited research and real work
  has been done in the area of the cooperative
  manipulation of music notation
• Why we need cooperation tools in music?
• Manual modifications (dynamics, expression marks,
  fingering etc.) on the score performed by the
  musicians and the conductor of an orchestra
  during rehearsals usually demand an enormous
  amount of time and work
• The cost of storing, maintaining or replacing
  multiple unique sets of parts of the old scores
  with new ones can be very high

3
Music Object Oriented Distributed System (MOODS)

• Moods is an integrated system of computer based
  lecterns for synchronous, real time cooperative
  editing, visualization and execution of music
  scores
• The system consists of
• Single part lecterns (Distributed LIOOs DLIOOs)
  for visualizing and editing single score parts
• One or more lecterns (Main Score Editors MASEs)
  for visualizing and editing the main score
• A general manager and music editor (Main Score
  Auxiliary Editor MASAE) for global modifications
  on the main score and revisions
• A database for managing the music archive

4
MOODS Architecture
5
These pictures have been taken at Teatro alla
Scala during the demonstration - 22 September
1998 -
6
These pictures have been taken during rehearsals
at Faculty of Engineering, University of
Florence, July 1998
7
MOODS and Visualization

• MOODS uses a formal and unified model for
  representing music that allows musicians to use
  different visualization and manipulation rules of
  the score
• What does this mean? End users can use various
  views of the same score, different window size
  and zooming factors, their own formatting and
  justification rules while editing simultaneously
  parts of the same score

8
MOODS and Representation

• The consistent and unique representation of the
  main score is managed by a real time inference
  engine called MILLA (Music Intelligent Language
  for Automatic Formatting)
• MILLA provides automatic formatting of the music
  based on specific rules
• End users can customize the MILLA rules of their
  lecterns. Hence they can change the visualization
  of music according to their needs

9
MOODS and Modes

• MOODS has two modes of operation
• Editing mode Music can be edited and viewed by
  more than one musicians simultaneously. Each
  change performed on a lectern sent in real time
  to MASAE and from there to the other DLIOOs and
  MASEs requesting the same part
• Execution mode Page turning of music is
  performed automatically (by MASAE) on each
  lectern. The rate of music execution (tempo) can
  be constant or can be changed dynamically in a
  real time basis by the director (or conductor)

10
DLIOO (up) and MASAE (down) during execution
11
MOODS and General Architecture
12
MOODS and Consistency Analysis

• MASAE communicates with the lecterns (clients) by
  using high level commands
• These commands referred to the music notation
  symbols based on an identification system (every
  elementary symbol has its own unique ID that
  specifies the position of that symbol in the
  hierarchical music model)
• A client can use commands in order to
• insert (INS) or delete (DEL) symbols (e.g.
  notes),
• add (ADD) or remove (DELF) symbol features (e.g.
  accidentals, markers)
• add (ADDH) or remove (DELH) horizontal symbols
  (e.g. crescendo)

13
MOODS and Consistency Analysis

• Problems related to lexical, syntactic and
  semantic inconsistencies are structurally solved
  in MOODS
• MOODS follows a specific communication protocol
  between the MASAE and the clients in order to
  prevent the production of any possible
  inconsistency in the music notation model

14
Communication protocol in MOODS
15
MOODS and Consistency Analysis

• The communication protocol and the unique
  identification of each music notation symbol
  provide to the system
• Causality Preservation (operations are executed
  in all sites with the same order)
• Convergence (even if the order of the
  arrival/execution of the operations is not the
  same in all sites, the result of the editing is
  the same for all)
• Intention Preservation (the execution result of
  an operation does not depend on the context.
  Hence the effect of the execution is common for
  all the sites)

16
Orchestra Configuration

• The main entities in the configuration of MOODS
  are the Parts/Groups, the available physical
  lecterns and the groups of musicians/directors
• The configuration process in MOOD system includes
  two tasks
• Identifying the properties and physical
  characteristics of each lectern (e.g. screen
  size, pointer type etc.)
• Assigning each part of the main score to
  different groups of physical lecterns
• The configuration can be done through the
  Orchestra Network Configurator Manager (ONCM)

17
MASAE and OCNM
18
Versioning of the main score

• The MOODS system supports not only manipulation
  of the original version but also processing of
  the new versions produced by the orchestra during
  rehearsals
• Log files called Additional Command Lists (ACLs)
  keep track of all the commands that once applied,
  allowing passing from the original version to the
  current version
• ACLs contain both global (main score) and local
  (part) changes performed in the orchestra

19
Versioning of the main score

• For the processing of ACLs, MOODS uses an
  additional command window. It is a tool that
  allows visualization of the loaded history of
  changes, filtering of changes, validation,
  invalidation or undo commands, saving or loading
  changes and so on.
• The MASAE operator by undoing or invalidate
  commands helps the system to avoid
  inconsistencies or to recover from them

20
Additional Command Window of MASAE
21
Experimental Results and Validation

• For each of the 57 skilled musicians that
  participated in the testing process there was a
  15 minute demonstration of the system
• A questionnaire was filled out by every
  participant. The research team received useful
  feedback about the usability of the system and
  the general reaction. Suggestions for further
  improvement were also provided
• The validation of the system shown high levels of
  usability and utility in music schools as well in
  orchestras but low interest for domestic use

22
Future Work

• The current research is focused on
• the synchronization of the theatrical special
  effects with the music during real performances,
• the cooperative work on music notation for
  virtual orchestras (???)
• the distance learning of music

23
Evaluation and Discussion

• The most useful feature of the system is the
  execution mode What musicians really need is an
  automatic page turning mechanism and not an
  automatic editing application!
• Another important feature is the ability to keep
  a record of different versions of the music
  score. It is useful, especially for the new
  musicians, to be able to compare the score of the
  same work performed by different conductors
• The cooperative editing feature probably is
  useful for the conductor but it is totally
  useless for the musicians of an orchestra. Most
  of the additional notation a musician use (e.g.
  fingers) has meaning only for him and not for the
  others. Furthermore, this additional notation
  does not always use formal music symbols or
  terminology (not supported by MOODS)

24
Evaluation and Discussion

• How the conductor changes the rate of the music
  execution in a real time basis? Taking into
  consideration that every part of his body
  participates in the art of conducting, it is
  impossible for him to adjust electronically the
  parameters of MASE
• I cannot see why is so difficult for the
  musicians of an orchestra to add symbols or
  symbol features with an easy and consistent
  wayMy personal experience says that the music
  terminology as well the measure numbers in the
  score are sufficient to support that kind of
  modifications or updates

25
(No Transcript)