Organised Soundhttp://journals.cambridge.org/OSO

Additional services for Organised Sound:

Email alerts: Click hereSubscriptions: Click hereCommercial reprints: Click hereTerms of use : Click here

CODES: a Web-based environment for cooperative music prototyping

EVANDRO MANARA MILETTO, MARCELO SOARES PIMENTA, ROSA MARIA VICARI and LUCIANO VARGAS FLORES

Organised Sound / Volume 10 / Issue 03 / December 2005, pp 243 - 253DOI: 10.1017/S1355771805000981, Published online: 29 November 2005

Link to this article: http://journals.cambridge.org/abstract_S1355771805000981

How to cite this article:EVANDRO MANARA MILETTO, MARCELO SOARES PIMENTA, ROSA MARIA VICARI and LUCIANO VARGAS FLORES(2005). CODES: a Web-based environment for cooperative music prototyping. Organised Sound, 10, pp 243-253doi:10.1017/S1355771805000981

Request Permissions : Click here

Downloaded from http://journals.cambridge.org/OSO, IP address: 143.54.12.213 on 19 Dec 2014

Organised Sound 10(3): 243–253 © 2005 Cambridge University Press. Printed in the United Kingdom. doi:10.1017/S1355771805000981

CODES: a Web-based environment forcooperative music prototyping

EVANDRO MANARA MILETTO, MARCELO SOARES PIMENTA,ROSA MARIA VICARI , LUCIANO VARGAS FLORES

Laboratório de Computação & Música (LC&M), Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRGS), CaixaPostal 15064, 91501-970 Porto Alegre, RS, BrazilE-mail: {miletto, mpimenta, rosa}@inf.ufrgs.br, lflores@cpovo.net

allowing users to make music experiments and interactwith each other in order to create simple musical pieces(herein named music prototypes or, simply, prototypes– see section 2).

The CODES project associates concepts of com-puter music, human-computer interaction (HCI), andcomputer supported cooperative work (CSCW) toallow lay people interested in music to experience andreinterpret the sense of creating and developing theirown musical culture and skills through the Web. LikeWeinberg (2002), we are interested in providing anyuser (from non-music experts and children to experi-enced musicians) an access to meaningful and engag-ing musical experiences. Through CODES, non-musicexperts may have the opportunity to be – like experi-enced musicians are – the actors of their own musicalexperiences. This means they can create musicalexamples (prototypes) that can be tested, modified,and repeatedly listened to, both by the first authorsand by their partners that will be cooperating in therefinement of the prototype. Moreover, such a coop-eration may foster the individual’s musical devel-opment, and so using CODES may also become aninitial stimulus to further interest in the formal studyof music.

This paper is organised as follows. The music pro-totyping concept is introduced in section 2. Section 3presents some reported experiences with cooperativemusical composition. The CODES system, its archi-tecture, and main characteristics are presented insection 4. Some characteristics of the CODES userinterface and interaction are presented in section 5.Section 6 highlights the support for cooperative activ-ities. Different uses for CODES are considered insection 7, and a final discussion, in section 8, concludesthe paper.

2. MUSIC PROTOTYPING

In industry, prototyping is usually adopted as acyclic process for the creation of a simplified versionof a product, so that its characteristics and processesof conception and construction can be understood.Prototyping aims at creating successive versions of

This paper presents CODES – COoperative MusicPrototype DESign, a Web-based environment forcooperative music prototyping. Its main goal is to allow anyuser – especially those with no expertise in music – to draftmusical pieces collectively, in a prototyping manner. So, suchmusical sketches – we call them music prototypes – can berepeatedly tested, listened to, and modified, not only by theiroriginal creators but also by the online partners that willcooperate in their refinement, until their final form isreached. CODES enables sharing of knowledge by means ofrich interaction and argumentation mechanisms associated toeach prototype modification, which are also secure ways ofproviding awareness to this asynchronous collaborativeenvironment. In this paper, we present the concept of musicprototyping and introduce the main aspects related tocooperative prototyping of musical pieces, focusing on issuesconcerning a musical piece as a collective creation of a virtualcommunity. We will also show some usage examples as ameans to describe the overall architecture, behaviour andpotentials of the CODES environment.

1. INTRODUCTION

Music technology has undergone considerablechanges over the last decade, mainly with the increas-ing use of the Internet. Even presenting some con-straints as for sound information traffic, the Internetis becoming increasingly attractive as a tool for musicmaking (Kon and Iazzetta 1998). An example of itspossibilities is networked music, as described in asurvey by Barbosa (2003), which allows experimentalartists to explore the implications of interconnectingtheir computers.

Day by day the Internet is growing as anenvironment for communication, data exchange, andinformation in all fields, shortening distances andproviding interaction facilities that support the growthof virtual communities. Indeed, Internet-based net-worked music has gained wider acceptance, and theexisting applications have evolved towards moresophisticated projects and concepts including, forexample, real-time performance systems and differentsystems for multi-user interaction and collaboration.

In this paper we introduce CODES – CooperativeMusic Prototype Design, a Web-based environmentfor cooperative music prototyping. CODES aims at

244 Evandro Manara Miletto et al.

the same product incrementally, providing newimprovements at each new version.

However, in the musical field, some peculiaritiesmake the creation and conception process differentfrom those carried out in other fields. Musical compo-sition is a complex activity where there is no agreementabout what activities have to be done and in whichsequence: each person has a unique style and way ofworking, and then most composers have not yet devel-oped the tradition of sharing their musical ideas andcollaborating while composing.

‘Prototyping’ is not a common expression in musicliterature. In fact, the activity carried out by compos-ers is usually called ‘composition’. But, in principle,non-specialists in music are not composers and theresults of their creative experiments are deliberatelycalled ‘music prototypes’ in this paper in order to high-light the difference. In the music literature, ‘draft’ iscommonly applied to such a kind of creative work, butour emphasis is mainly on the process (prototyping),and not on the product itself (in which case ‘prototype’or ‘draft’ correspond to the same idea).

In our opinion, music is an artistic product that canbe designed through prototyping. A musical idea (anote, a set of chords, a rhythm, a structure or a rest) iscreated by someone (typically for a musical instru-ment) and afterwards cyclically and successively modi-fied and refined according to his/her initial intentionor to ideas that come up during the prototyping pro-cess. Besides musicians, non-specialists in music arealso probably interested in creating and participatingin musical experiments, but they lack environmentsoriented to their profile. In fact, we believe no previousmusical knowledge should be required by any user tocreate music prototypes.

3. RELATED WORK

This section summarises the characteristics of someenvironments found in the literature for collectivemusical composition. Clearly, most of these environ-ments are for music composition by music specialists,rather than for music prototyping by non-specialists.The major motivation underlying our proposal is toallow non-specialists in music to access a virtual spacein order to interact with each other, explore soundstogether, discuss this exploration, and retrieve all thediscussed information any time they want.

In a survey about IMNs – interconnected musicalnetworks – Weinberg proposes four different levels ofinterconnectivity among participants, based on theroles the computer plays in enhancing their interde-pendent social relations: ‘The Server’, ‘The Bridge’,‘The Shaper’, and ‘The Construction Kit’ (Weinberg2002). Most of the Internet-based systems for musiccomposition described here are cited in that surveywithin the last level, ‘The Construction Kit’. In this

level, there is high interconnectivity among partici-pants, who are usually experienced musicians. Partici-pants are allowed to provide their own material andmanipulate (listening, altering, refining, etc.) others’contributions, usually in an asynchronous interactionand offline material manipulation.

The PIWeCS (Whalley 2004) system is a complexcomposition system based on a dialogue betweenhuman and non-human agency. PIWeCS integratesintelligent agents with Max/MSP software througha Web user interface. The system would have to workin a physical space like an art gallery, but also onlinefor off-site participants, and be suited to combine bothpoints of access, whilst CODES was designed to runin a virtual space only via a Web browser to eliminatethe barrier of geographic distance among partners(physical presence).

The FMOL system (Jordà 2000) is related to real-time collaborative musical composition on the Web.Using a plug-in, the system allows many distributedusers to work together in one or more musical works.Collaboration is carried out with a vertical multi-trackmodel. FMOL implements interesting and complexsynthesis concepts that are more indicated for skilledusers instead of concepts that were designed to beuseful and usable for non-music experts as in CODES.

The EduMusical system (Ficheman 2002) supportscollaborative and interactive distance learning, aimingat teaching music to children and teenagers, orientedby music instructors from an actual orchestra –OSESP, the Symphonic Orchestra of São Paulo. Col-lective composition is possible through the interactionbetween students in virtual classrooms, guided by atutor. In contrast, CODES allows independence froma tutor and non-structured groups, despite the possi-bility of supporting structured groups with a tutorrole usually necessary in learning situations (Miletto,Pimenta and Costalonga 2004).

The TransJam system (Burk 2000) aims at allowingmusicians, who are connected to its website, to makemusical performances together, selecting loops of theinstruments that are to be played. Despite the focusbeing on supporting performance, there is some simplesupport for composition here. Daisyphone (Bryan-Kinns 2004) is an environment for remote group musicimprovisation presenting a novel design for moreengaging social and serendipitous musical environ-ments. Daisyphone focuses on the representation oflooping music, and provides support for remote col-laboration, and support for the formulation of ideas.Both TransJam and Daisyphone are systems based ona looping metaphor that could present some disadvan-tage related to style and rhythm flexibility. CODEStries to overcome this by offering users the possibilityof creating multiple lines with different music stylesand rhythms, and even mixing them in the sameprototype.

CODES 245

PitchWeb (Duckworth 2000) is a multi-user musicalinstrument specifically designed for the Internet. Basi-cally, it uses plane geometric shapes (figures) that canbe selected and manipulated, and finally mapped ontosound samples that need to be downloaded to thebrowser cache before starting the system. The userinteraction in the environment allows for choosingthe order in which samples will be played, representedby the shapes. There are other systems that deal withcomposition, like Creating Music (Subotnick 2004)and HyperScore (Farbood, Pasztor and Jennings2004), which enable non-musicians to compose (orcreate), collectively or not. Our approach differs fromthese works mainly regarding HCI issues. They needadditional plug-ins and software installed (likeShockwave Flash and QuickTime Player) to run.CODES is designed to be accessible to a great diversityof platforms and browsers (all W3C compliant – seeW3C 2004), minimising requirements of use and thusincreasing accessibility.

Rolf Wöhrmann and Guillaume Ballet’s (1999)article examines client-server architectures for com-puter music, drawing upon the example of IRCAM’sStudio Online project. The authors outline a numberof issues in distributing sound-processing and data-base services over the World Wide Web. The systemthey describe is addressed to skilled musicians insteadof non-music experts as in our case.

Some aspects – mainly regarding technologicalconcerns – are common to most of these systems:

• adoption of a client-server architecture;• use of the MIDI sound format;• implementation in a platform-independent Java

language – except FMOL, implemented in C++and available only for Windows or Linuxoperating systems; and

• unrestricted access to ordinary users, i.e. any usermay login or access the system without anadditional fee.

Most of these systems could be used by non-experienced users; in practice, however, more skilledusers may obtain better results if they have specificknowledge about sound synthesis (in the cases ofFMOL and the system described by Wöhrmann andBallet) or if the activities are carried out under atutor’s supervision (in the case of EduMusical).

In addition to common characteristics of othersystems (such as the ones briefly discussed above),CODES addresses three other aspects that are veryimportant to consider in a collaborative environmentfor music composition/prototyping:

(1) Group awareness: mechanisms to manage under-standing of actions and decisions of groupmembers. In fact, similar works do not have anysupport for group awareness. More details about

the CODES group awareness mechanisms arepresented in section 6.

(2) Support to long prototyping sessions: an importantmechanism in prototyping sessions – in fact, inany design activity – is the capacity of interruptinga session and resuming it in order to continue theprocess from the last break point. A musicprototyping session can take many days or evenweeks before a final result is reached.

(3) Export/import sound format: providing soundrepresentation formats in order to allow export/import musical pieces/prototypes from/to oneenvironment/system to/from others. Currentlyavailable formats are the well-known MIDI andWave. Standard MIDI was chosen here due toeasy manipulation and compatibility. Althoughthe sounds of synthesised MIDI files played onmost PCs are still low quality, it yields some futurepossibilities, like conversion from MIDI tocommon music notation. We are investigating theuse of some markup languages for music – likeMusicXML, Music Markup Language (MML),Music Encoding Initiative (MEI), and StandardMusic Description Language (SMDL) – as inter-esting alternatives to be explored. We believe thatin the near future one of them (or some variationthereof) will be the standardised format of choicefor music content on the Web.

One of the crucial aspects that gives CODESan advantage over the systems described above isthe communication concept that is necessary toimplement cooperative work, which we discuss insection 6.

4. THE CODES ENVIRONMENT

CODES is an environment for cooperative musicalprototyping on the Web, designed to be used by peopleinterested in music who wish to prototype and sharetheir musical ideas. A major requirement of CODESis that it should support music prototyping in such acooperative way that users would not need to beskilled musicians or to have any specialised knowledgeof music to use CODES and create music prototypes.In this section we will present a brief description of itsarchitecture and implementation aspects.

CODES is based on the classical client-serverarchitecture (figure 1). On the client side, the SonicManipulation Manager Applet manipulates sound(sound files selection, mixing, playing, stopping, etc.),sending user events to CODES managers on the serverside. Actions such as invitations, adding comments tomusical pieces, and event perception are manipulatedby the Cooperation Manager, together with the UserManager, to verify user’s authentication. Sonic pat-terns are organised on the server side through theSonic Pattern Manager, which reads the directories,

246 Evandro Manara Miletto et al.

updates and retrieves files that are required by theSonic Manipulation Manager. All activities related tothe user (login, register, authentication) are performedby the User Manager, which communicates with theCooperation Manager to execute cooperation actionsamong users and groups. The Database Managerprovides access to the database, where MIDI files,application data (messages, logs, etc.), and user dataare stored.

CODES implementation follows a free softwarephilosophy, aiming at providing easy access to soft-ware development tools. The Java Sound API, fromJava programming language, allowed us to focussystem development on both graphical user interface(GUI) and cooperation aspects, making the soundhandling easier because of the components thatalready offer sound control. The Web server used wasTomCat Servlet Container (TomCat 2005), a refer-ence for Java applications that accesses a MySQL(MySQL 2005) database through a JDBC connection(JDBC 2005).

5. CODES USER INTERFACE ANDINTERACTION

The CODES user interface was designed to coveraspects related to interaction flexibility, robustness,and ease of use, as well as to present adequate supportwhen complex musical information is displayed, thusproviding an effective interaction between users andenvironment. The environment was designed to reacha balance between user interfaces that are so ‘easy’ forthe user that they end up depleting their expressive-ness, and others that are so complicated that theydiscourage beginners (D’Arcangelo 2002).

CODES understands a musical prototype as formedby lines (tracks) of instruments and arrangements,such as bass, arpeggios, drum lines, etc. Editing istypically made by selecting sonic patterns amongpre-defined patterns available in CODES. A user isallowed to create more than one line, which meansthat someone can be the ‘owner’ of more than one line(like user 1 in figure 2). By clicking the Play button, theSonic Manipulation Manager starts the execution ofthe selected lines, that is, all lines enabled for playback(option Mute unselected – see muted line in figure 2).All chosen patterns vertically grouped in the sametimeline are mixed and played, under complete usercontrol (see time 3 in figure 2), which can stop andrestart at any time with the usual control buttons(Play, Stop, Forward, Rewind, Pause).

User interaction, therefore, basically includesactions such as ‘selecting’ (by clicking) and playingsonic patterns, and combining them with other pat-terns selected by the ‘partners’ (other users) of thesame music prototype. This combination can occur indifferent ways: overlapping (simultaneous playing),juxtaposition (sequencing), etc. Sonic patterns arehigh-level musical structures (small parts of musicalfiles in MIDI format) that make the process of soundchoice and prototyping easier. The possible patterns ofchoice for a cell have small sonic differences, but keepthe same style and same duration, which makes iteasier for the user to adapt them to his/her piece.

Many musical elements are pre-defined in theCODES system patterns, including concepts such asrhythm, tempo, melody, harmony and timbre. Usersdo not need to know the conventional music notation(score) to create prototypes: they may select, play andcombine such patterns in an interactive way by directmanipulation.

Figure 1. CODES architecture.

CODES 247

Other user interface details can be identified infigure 2. Three users (user1, user2 and user3) are thetrack owners of the four existing lines L1, L2, L3 andL4. The Post-it icon (see line comments in the figure)indicates the presence of a user note or of an argumen-tation related to some action carried out in that line.Lines L3 and L4 belong to other users, and a possibleaction for the active user (user1) is to mute themduring execution, by selecting the check box with thelabel Mute, as in line L4.

Users may begin building their musical prototype inCODES by choosing a new line, which will representthe music genre or style. Such choice will determinewhat kind of sound pattern will be made availablefor the users of that particular music prototype (forexample: pop rock, bossa nova, blues, jazz, etc.). Anoverview of a line creation can be seen in figure 3. Thefirst step when creating a new line is to open the ‘Edit’menu and click ‘Add line’ (figure 4). A new windowwill open and the user will choose a musical style forthat line (see the example of a jazz style in figure 5).Then, the user has to choose what we refer to as a‘musical component’, where the options are rhythm,bass, notes, and base (chord) (figure 6). Each cell cre-ated in the line will launch the same collection of soundpatterns, according to the users’ choices. Thus, they

can combine the sequence they consider the mostadequate.

6. COOPERATIVE ACTIVITIES IN CODES

Cooperative music prototyping is here defined as anactivity that involves people working together on amusical prototype. Cooperation in CODES is asyn-chronous, since it is not necessary to manage thecomplexity of real-time events for the development ofmusical prototypes. Users can access the prototype, dotheir experiments, and write comments at differenttimes and from any location, via a Web browser.

CODES considers that a musical prototype is initi-ated by someone, the prototype owner. He or she usesCODES to elaborate an initial musical prototype andto ask for the collaboration of other ‘partners’, bysending explicit invitations (typically using e-mailfeatures). Partners who accept the invitation can par-ticipate in the collaborative musical refinement andmanipulation.

The coordination (one of the characteristics ofcooperative work) of all activities in such a musicalcontext can happen naturally, when the group recog-nises one member as having more musical abilities,being more experienced or simply willing to take the

Figure 2. Elements of the CODES editing window.

248 Evandro Manara Miletto et al.

lead. We believe that it is not necessary to make dis-tinct and explicit representation of coordinator role,because hierarchisation of group actions and commu-nications is not our intention. Usually, more experi-enced users’ opinions and actions in a group with anexplicit coordinator role may inhibit the other users’participation.

The group of partners of a prototype in CODESmay evolve into a virtual community, and so CODESmay be considered as a communityware (Liechti 2000)for entertainment. Typically, communityware aims atsupporting the formation of informal groups of peopleand at supporting the interactions in such communi-ties. In order to provide support for these interactions,CODES offers three kinds of awareness mechanisms:

(1) Music prototyping rationale: to allow users to linktheir explanations with their actions on musicprototypes;

(2) Action logging: to maintain an explicitly recordedtrail of the steps that led to the current prototypestate; and

(3) Modification marks: to indicate to a user that aprototype has been modified by others.

In fact, awareness mechanisms offer several benefits tomusic prototyping:

• keeping track of decisions;• tracking progress in music prototyping and iden-

tifying conflicts, which may initiate a negotiationprocess among multiple points of view;

Figure 3. Creating a jazz line.

Figure 4. Adding a new line.

Figure 5. Choosing a musical style.

Figure 6. Choosing a musical component.

CODES 249

• supporting the building of cumulative prototypingknowledge;

• assisting the integration of perspectives frommultiple members of a group; and

• enabling comparison of alternative solutions toone determined music prototyping problem.

The awareness of group members plays a crucial rolein supporting cooperative and multidisciplinary activi-ties in CODES. The main aspects of these awarenessmechanisms are discussed below.

The Music Prototyping Rationale Mechanism is aneffective way to represent and record explanations foreach action or decision made during the musicprototyping process. Each user may associate com-ments in favour or against any action on a prototypeelement. The ability to associate such comments tosteps in the design process is an aspect originally pro-posed in the human-computer interaction field, andcalled ‘Design Rationale’, abbreviated DR (Lee andLai 1991). Design Rationale is a communicationmechanism for the design team to communicate pastcritical decisions, what alternatives were investigated,and the reasons behind the chosen alternative (Moranand Carroll 1994). As an immediate consequence, itencourages deliberation and explicit consideration ofalternatives. There are many models and notations forDesign Rationale, like the Issue-Based InformationSystem (IBIS) (Conklin 1998) and the Questions,Options and Criteria (QOC) notation (MacLean,Young, Bellotti and Moran 1991). Nowadays, DR isadopted also by other disciplines (like, for example,Requirements Engineering, and Systems Engineering)and recognised as a possible way to allow a groupmember to obtain a better understanding of othergroup members’ actions and decisions. Musicalactions and decisions are usually subjective. It isimportant therefore to have a specific communicationmechanism for commenting on actions, in order to

inform the reasons of such actions to the other mem-bers of the group, such as the selection of a particularsound pattern, instrument, rest, etc., or the decisionof making combinations or deleting some prototypeelement.

We consider the process of creating music ormaking musical experiments to be also a process thatcan be composed by objective decisions and choices.When the users are prototyping in CODES, they com-bine the musical or sound pieces in their line with otherpieces from others’ lines. Thus, choices, selections,enabling, disabling and execution tasks are performedconstantly in a cyclic process until an agreement aboutthe prototyping result is achieved. All of these actionscan be argued in CODES by users in order to informthe other users about the reasoning behind theseactions. This is a sound way to provide awareness inasynchronous collaborative environments.

In CODES, Music Prototyping Rationale basic ele-ments are issues and comments. Issues correspond todecisions or actions that have been made or states thathave been achieved during a collaborative musicprototype creation and refinement. For example, anissue can be ‘Change instrument line Y’, ‘Insert pauseat time 4’ or ‘Mixing different rhythms’ (see Subjectin figure 7(a)). Issues are goal-motivated consensualchoices, concerning alternatives of the action course.

Comments are asserted in order to support theselection of a specific course of action (comments infavour) or avert the users’ interest from it by express-ing some objection (comments against). Additionally,comments may express some suggestion, question orgeneric observation about the issue. Comments areconsensual explanation, not an individual messageinterchanged between actors. Therefore they are nota specific kind of message. Every decision or actionmay be linked to comments (in favour or against) (seeContent in figure 7(a)).

Figure 7. Screenshots of CODES comment windows.

250 Evandro Manara Miletto et al.

A practical example of the Music PrototypingRationale, after a rhythm experiment session donein the CODES environment, is described as follows.Three users participate in the same music prototype,namely Alex, Neil and Geddy. Each one of themcreates one line in the prototype according to theirpreferred skills. However, Alex has the idea of mixingdifferent styles of rhythms and decided to createanother drum line of jazz inside a pop style. In order toobtain feedback from the other partners cooperatingin this prototype, Alex writes an explanation for hisaction.

In the comment window, the edition of a commentincludes the comment subject and the free-style bodyof the comment. The user can assign to a comment anoptional feature, the property Private, in the case ofjust registering the comment for himself, becauseit should be invisible to others. The default value isPublic, where the comments are visible to everymember (figure 7(a)). Then, CODES saves the com-ment and associates it with the corresponding proto-type issue, informing other users by a Post-it icon (seecomments in figure 2) that some comment was madeby some user related to some action carried out in thisline. By clicking the icon, a user can retrieve thecomment.

As shown in figure 7(b), our approach of MusicPrototyping Rationale uses a hierarchical structure torepresent the reasoning of users. Each entry in thedescription corresponds to an argumentation element.In that applet window each element is accompaniedby three icons, one (+/-) for folding/unfoldingpurposes, the second (the magnifying glass) indicating

that the comment was read, and the last (the soundmonitor) indicating that a sound event was listened toby the corresponding user. Finally, each entry in thestructure may contain its author’s username and thecontent of the comment. As users can manipulatethe prototype at different times, access to MusicPrototyping Rationale in CODES is easy and possiblefrom any location.

Action Logging – CODES has an Action Loggingmechanism to record some information (like date,author, action, prototype element affected, etc.) fromall actions, making them available for all partners toobserve what was done and in which sequence. TheAction Logging is responsible for textually presentinga history of all actions by users via the system. Whenusers perform actions on the prototype (login, logout,select sound pattern, add explanations, etc.), theyare recorded by the system. The result is a GroupMemory, a common database for all users sharing thesame musical prototype and allowing users to under-stand not only their own activities (querying thehistory recorded in the group memory) but also theactivities of other group members.

Figure 8 shows a sample screen of CODES, where itis possible to view an excerpt from an Action Loggingorganised in a chronological sequence. The user canalso browse it in order to search previous actions. Asshown in figure 8, the user can filter the level of infor-mation registered by events triggered by the system.By browsing, all users can track progress in therecorded trail looking for the steps that led to thecurrent prototype state.

Figure 8. Excerpt of Action Logging.

CODES 251

Modification Marks – While CODES supports longprototyping sessions, cooperative activities and proto-type modifications can take place over an extendedbut limited period, from a few days to possibly severalweeks. Under these conditions, people cooperatingin music prototyping construction should have easyaccess to the modifications that have emerged fromtheir activities. Thus these modifications should ofcourse be maintained across sessions, and notificationof their existence should be explicitly shown for otherusers. This is the main motivation for the CODESModification Marks mechanism. As mentionedbefore, every time there is a change in a prototype,CODES triggers an event that is recorded automati-cally in the Group Memory (Action Logging). In orderto indicate to a user that a prototype has been modi-fied by others, the icon ‘N’ indicating ‘New’ appearsin the line rendering.

Finally, cooperation in CODES can provide inter-esting alternatives for beginners in music. By means ofinteractions with and advice from more experiencedusers, CODES provides a support for beginners’learning, a positive interdependency, encouragingcollaborative actions, argumentation, discussion andcooperative learning during the development of amusic prototype. This becomes more clear if analysedfrom the perspective of Vygotsky’s (1978) work, whichsuggests that social interactions play a fundamentalrole in shaping internal cognitive structures. Accord-ing to Vygotsky, cognitive development derives fromthe person’s engagement in cooperative problemsolving. In these situations, the learner is forced toexamine his thinking when challenged by others, andin turn to keep an eye out for possible mistakes madeby his collaborators.

7. ALTERNATIVE USES FOR CODES

This section discusses other possibilities and situationswhere CODES can be used. CODES has been appliedin a number of small-scale studies in order to evaluateits use, identify and correct problems, and determinenew requirements. The results to date express the rela-tive success of our work, but surprisingly one of themost interesting results is the set of alternative app-lications the users found for CODES. In addition tothe ‘conventional’ edit-listen-publish-cooperate-refineprocedure for which we have initially developedCODES’ functions, users were able to find othercreative ways of using it:

• as an effective support for music learning;• as an entertainment tool; and• as an accompaniment system for human

performance.

In music learning situations, CODES can provideinteresting alternatives for beginners (Miletto, Pimentaand Costalonga 2004; Miletto, Pimenta and Vicari

2005). A realistic scenario would be as follows: a col-lective prototype is created by a group formed by stu-dents and supervised by a music teacher. The groupcan carry out musical experiments leading to a musicprototyping situation where each student plays adefined role and is responsible for an activity to bedeveloped in this prototype. The group, through inter-actions and the advice of the teacher, decides whichmusical genre will be studied, as well as the number andthe kind of instruments and music structures that willbe put together in the prototype. Then, it is possibleto work on music creation collectively, using the meta-phor of a musical orchestra: each student plays adefined role in the final result. In addition, the teachercan enable several patterns related to the same instru-ment for different students, and all students can com-pare their different contributions, choosing or mixingalternatives. The teacher can also apply concepts ofmusical dynamics and expressiveness, indicating dif-ferent sonic structures in different moments of theprototyped musical discourse. Thus, the combinationof both cooperative music prototyping and musiceducation is a promising one, and merits additionalresearch. In particularly, our intention is to providecomputer-supported features for music educationfollowing Keith Swanwick’s C(L)A(S)P model(Swanwick 1979), as we have already done in previousworks (Krüger et al. 1999; Flores et al. 2001).

As an entertainment tool, CODES provides inter-esting experiences to users involved in musical activi-ties like those carried out by DJs/producers (cutting/pasting metaphor). Choosing sound patterns from thesystem, users have the possibility of mixing differentrhythms, music parts and styles just by having parallellines of each of them playing together. Also, with acollection of added lines with sound patterns selected,the user can produce many styles of a music prototypejust by enabling and disabling the groups of lineshe wants, experiencing different combinations ofsonority.

Another possibility is to use CODES as an accom-paniment system for human performance. An indi-vidual skilled user created some lines in CODES inorder to imitate the performance of a music group (aband). As she plays guitar, the lines of bass, rhythmand chords (base) were played back while she playedher musical instrument. Thus, in this situationCODES is considered as an auxiliary tool forinstrument practice and self-training.

As a communication tool, CODES also provides thepossibility of use in music discussion forums, whereusers can – by means of a message board mechanism –participate in discussions and reasoning about regis-tered ideas. An important feature of CODES is thepossibility of users linking their explanations withtheir respective music prototypes. We are currentlydocumenting these alternative usages of the system fora more systematic evaluation.

252 Evandro Manara Miletto et al.

8. FINAL DISCUSSION

The CODES approach for cooperation among users inorder to create collective music prototypes is promis-ing, because it enables knowledge sharing by meansof rich interaction and argumentation mechanismsassociated with each prototype modification. Conse-quently, each participant may understand the prin-ciples and the rules involved in the complex process ofmusic creation and experimentation. Through com-puter technology, CODES provides an effective wayfor breaking down some barriers for people (especiallynon-musicians) who wish to engage in musical pro-totyping and experimentation. Of course, the musicalquality of the finished work is not under discussionhere, only the mere possibility of ‘creating it’.

The initial barrier to non-specialists in music isrelated to the possession of musical instruments. His-torically, it was necessary to own or have access to aninstrument to be able to investigate sound possibilitiesor try composing/playing sounds and music. Now, theuse of multimedia computers associated with soundcards and virtual instrument software has ‘freed’people from the need for a physical instrument to per-form and compose music. We do not advocate thatthis is a better scenario for music making, but it is afact, which is present reality. The objective of ourwork is to devise tools that take advantage of this factin order to empower the non-specialist to create music.

Another barrier is the necessity of knowing commonmusic notation (the score). This notation (staff andsymbols) is fundamental for a deep and completelearning of musical theory, despite its complexity.However, it may pose some resistance for the layman.A non-specialist in music may consider it as an imme-diate practical obstacle because he needs to learn agreat number of symbols and how to use them to pro-duce musical material. Using CODES, one does notneed to understand conventional music notation tocreate prototypes: he or she may select, play and com-bine sound patterns in an interactive way, withouttaking into account their representation format. Yet,the possibility of conversion from musical prototypeto score version is one of our next goals, in order toprovide more pedagogical support and understandingof musical theory.

CODES was made available for use by actual usersin our academic context. Taking into account somewell-known subjective evaluation methods from theHCI and Ergonomics literature (Dix, Finlay, Abowdand Beale 1998), we have employed user-satisfaction-oriented interviews as a simple evaluation procedure.In order to capture all comments and criticism (andalso to avoid non-recorded opinions), users wereinvited to answer all questions in loco, immediatelyafter using CODES. The interview contains few objec-tive questions, takes only a few minutes to answer, itsdata analysis is quick and easy, and the whole processcosts very little.

The questions were conceived to identify adequacyof information ordering and structuring for useractivities during prototype creation/editing and col-laboration. This includes specific items about usabil-ity, accessibility, navigation complexity, and finally ifusers were satisfied with the implemented functional-ity. In addition to the objective answers, the interviewgave users the opportunity to include comments, andso, for us, an opportunity to examine these commentsformally.

Preliminary results show the need for improvementswith respect to some aspects of the CODES interface,such as:

• providing a better time control, enabling the userto stop at any time and resume playback fromthat time;

• allowing listening to the sound pattern beforeentering it into the timeline;

• allowing users to upload their own sound patternsinto the lines of CODES; and

• providing the standardisation to representmusical information in the GUI.

An aspect remaining to be explored is the implementation of real-time interaction in the CODESarchitecture. Interaction among users in a synchro-nous mode may bring up new features and propertiesnot considered until now.

The ultimate goal of our work is to make CODESavailable for public use, to expand our audience andachieve our intent of providing universal access to theexperience of the creative act. As people interested inmusic experimentation become more sophisticated,tools supporting this process need to employ more effi-cient technologies and approaches in order to addresstheir complexity and diversity. The present work sug-gests that cooperative music prototyping may becomean increasingly important topic in this regard.

ACKNOWLEDGEMENTS

The authors would like to thank Eduardo ReckMiranda (Future Music Lab, University of Plymouth,UK) for his advice on this research project andcomments on this paper. This work was partially sup-ported by the Brazilian research funding councilsCNPq and CAPES.

REFERENCES

Barbosa, A. 2003. Displaced Soundscapes: a survey of net-work systems for music and sonic art creation. LeonardoMusic Journal 13: 53–60. Cambridge, MA: MIT Press.

Bryan-Kinns, N. 2004. Daisyphone: the design and impactof a novel environment for remote group music improvi-sation. Proc. of DIS2004 – ACM Symp. on DesigningInteractive Systems, pp. 135–44. August, Cambridge,MA. New York: ACM Press.

CODES 253

Burk, P. 2000. Jammin’ on the Web: a new client-serverarchitecture for multi-user musical performance. Proc. ofthe Int. Computer Music Conf. (ICMC2000), pp. 117–20.Berlin: ICMA.

Conklin, J. 1998. The IBIS Manual: A Short Course in IBISMethodology. http://www.touchstone.com/tr/wp/IBIS.html

D’Arcangelo, G. 2002. Creating a Context for MusicalInnovation: a NIME curriculum. Proc. of the 2002Int. Conf. on New Interfaces for Musical Expression(NIME-02), pp. 102–5. Dublin, Ireland. Limerick, Ire-land: Department of Computer Science and InformationSystems, University of Limerick.

Dix, A. J., Finlay, J. E., Abowd, G. D., and Beale, R. 1998.Human-Computer Interaction, 2nd edition. Prentice-Hall.

Duckworth, W. 2000. Making music on the Web. LeonardoMusic Journal 9: 13–18. Cambridge, MA: MIT Press.

Farbood, M. M., Pasztor, E., and Jennings, K. 2004.HyperScore: a graphical sketchpad for novice compos-ers. IEEE Computer Graphics and Applications 24(1):50–4.

Ficheman, I. K. 2002. Collaborative Distance LearningSupported by Interactive Electronic Media: A Case Studyin Music Education. Dissertation. M.Sc. degree in Com-puter Science, Escola Politécnica da Universidade deSão Paulo, São Paulo. http://www.edumusical.org.br/(in portuguese).

Flores, L. V., Vicari, R. M., and Pimenta, M. S. 2001. SomeHeuristics for the Development of Music EducationSoftware: first steps towards a methodology. In Proc. ofthe 8th Brazilian Symp. on Computer Music. Fortaleza,Brazil. Niterói, Brazil: Instituto Doris Ferraz de Aragon.1 CD-ROM.

JDBC (2005), Java Data Base Connector. http://java.sun.com/products/jdbc/

Jordà, S. 2000. Faust Music On Line: an approach to real-time collective composition on the Internet. LeonardoMusic Journal 9: 5–12. Cambridge, MA: MIT Press.

Kon, F., and Iazzetta, F. 1998. Internet Music: dream or(virtual) reality? Proc. of the 5th Brazilian Symp. on Com-puter Music, pp. 69–81. Belo Horizonte, Brazil: Escolade Música / UFMG.

Krüger, S. E., Fritsch, E. F., Flores, L. V., Grandi, R. H.,Santos, T. R., Hentschke, L., and Viccari, R. M. 1999.Developing Software for Music Education: an inter-disciplinary project. Proc. of the 6th Brazilian Symp.on Computer Music, pp. 251–64. Rio de Janeiro:EntreLugar.

Lee, J., and Lai, K.-Y. 1991. What’s in design rationale?Human-Computer Interaction Special Issue on DesignRationale 6(3&4): 251–80. Mahwah, NJ: LawrenceErlbaum Associates.

Liechti, O. 2000. Awareness and the WWW: an overview.ACM SIGGROUP Bulletin, 21(3, December): 3–12.ACM Press.

MacLean, A., Young, R., Bellotti, V., and Moran, T. 1991.Questions, Options and Criteria: elements of designspace analysis. Human-Computer Interaction SpecialIssue on Design Rationale 6(3&4): 201–50. Mahwah, NJ:Lawrence Erlbaum Associates.

Miletto, E. M., Pimenta, M. S., and Costalonga, L. L. 2004.Using the Web-based environment for cooperative musicprototyping CODES in learning situations. Proc. of the7th Int. Conf. on Intelligent Tutoring Systems, pp. 835–7.Maceió, Brazil. Springer-Verlag.

Miletto, E. M., Pimenta, M. S., and Vicari, R. (in press)Using Codes: cooperative music prototyping and itseducational perspectives. In Proc. Int. Computer MusicConf. (ICMC2005), Barcelona.

Moran, T., and Carroll, J. 1994. Design Rationale: Concepts,Techniques and Use. Hillsdale, NJ: Lawrence Erlbaum.

MySQL. 2005. MySQL Database Server. http://www.mysql.com/

Subotnick, M. 2004. Creating Music. http://creatingmusic.com/

Swanwick, K. 1979. A Basis for Music Education. London:Routledge.

TomCat. 2005. TomCat, Apache Jakarta Project. http://jakarta.apache.org/tomcat/

Vygotsky, L. S. 1978. Mind in Society. Cambridge, MA:Harvard University Press.

W3C. 2004. World Wide Web Consortium. http://www.w3.org/

Weinberg, G. 2002. The aesthetics, history, and futurechallenges of interconnected music networks. In Proc.of ICMC 2002. Göteborg, Sweden: ICMA.

Whalley, I. 2004. PIWeCS: enhancing human/machineagency in an interactive composition system. OrganisedSound 9(2): 167–74. Cambridge, UK: CambridgeUniversity Press.

Wöhrmann, R., and Ballet, G. 1999. Design and Architec-ture of Distributed Sound: processing and databasesystems for Web-based computer music. Computer MusicJournal 23(3): 73–84. Cambridge, MA: MIT Press.