Overview of PWGL PDF

An Overview of PWGL,a Visual ProgrammingEnvironment for Music

Mikael Laurson, Mika Kuuskankare,and Vesa NoriloCentre for Music and Technology (CMT)Sibelius AcademyP.O. Box 8600251 HelsinkiFinland{laurson, mkuuskan, vnorilo}@siba.fi

This article provides an overview of our free Lisp-based, cross-platform, visual programming environ-ment called PWGL (the name is an acronym forPatchWork Graphical Language). PWGL can be usedfor computer-aided composition, music analysis,and sound synthesis. Our work is influenced byour past experience with PatchWork (Laurson 1996;Assayag et al. 1999). However, PWGL has beencompletely rewritten and redesigned in our attemptto develop and improve many of the useful conceptsbehind PatchWork.

PWGL and several of its applications havealready been discussed in our previous work,including Laurson and Kuuskankare (2002, 2006),Kuuskankare and Laurson (2006), and Laurson,Norilo, and Kuuskankare (2005). Since 2002, PWGLhas undergone several revisions and additionsincluding the public release, launching of thePWGL home page, inclusion of the tutorials andnew programming interfaces, etc.; each of thesehave been attempts to make our system moreavailable and more easily approachable within thecomputer music community. The main purpose ofthe present article is to give a general overview ofthe current state of the system with an emphasison features that are useful for potential PWGLusers, such as composers, music analysts, andresearchers.

PWGL is programmed ANSI Common Lisp(Steele 1990) from LispWorks (www.lispworks.com),which is source-code compatible across severaldifferent operating systems, such as MacintoshOS X, Microsoft Windows, and Linux. LispWorksprovides support for Foreign Language Interfaces,by which a program written in one programminglanguage can call routines or make use of serviceswritten in another. LispWorks also supports theOpenGL graphics library API. (The graphics part

Computer Music Journal, 33:1, pp. 19–31, Spring 2009c© 2009 Massachusetts Institute of Technology.

of PWGL is based on OpenGL.) The use of thesame codebase aids the development process and indistribution to multiple platforms.

PWGL integrates several programming paradigms(functional, object-oriented, and constraint-based)with high-level visual representation of data, andit can be used to solve a wide range of musicalproblems. A PWGL patch is the main workspacewhere the user can add boxes and create relationsamong them using connections. In its simplestform, a PWGL patch can be seen as a visualizationof Lisp: a patch consists of boxes that represent Lispfunctions or Common Lisp Object System (CLOS)methods. As PWGL provides a direct interface toits base languages, every Lisp function or CLOSmethod can be automatically transformed into abox. As a result, PWGL offers the flexibility of botha traditional text-based programming language anda visual programming language. Besides a library ofbasic boxes (e.g., arithmetic, Lisp functions, list han-dling, loops, abstractions, and conversion), PWGLcontains several large-scale applications, such as theExpressive Notation Package or ENP (Kuuskankareand Laurson 2006), 2D-Editor (Laurson andKuuskankare 2004), PWGLSynth (Laurson, Norilo,and Kuuskankare 2005), and PWGLConstraints(Laurson and Kuuskankare 2005).

Currently, PWGL runs under Macintosh OS X10.4 and 10.5 (Universal Binaries) and WindowsXP operating systems. PWGL is distributed intwo different configurations: as a standaloneapplication—PWGL Application—that is targetedmainly to end-users, and as a developers version—PWGL Binaries—that requires the LispWorksprogramming environment. The latter version ismade available as a pre-compiled module that isloaded on top of LispWorks. The downloads aremade available through our projects home page atwww.siba.fi/PWGL. Our Web page also includeslinks to some introductory material, examples,news, and a comprehensive support section.

Laurson, Kuuskankare, and Norilo 19

The most important key features of PWGL areits high-quality visual appearance; its ergonomic,uniform, and efficient graphical user interface; theability to operate visually and directly with high-level musical data; powerful intermixing of textualand visual programming; tight integration of itsmajor tools (i.e., music notation, sound synthesis,scripting, and constraint-based programming); andcross-platform code-base.

The rest of this article is organized as follows. Westart by comparing PWGL to two other Lisp-basedcomposition environments. Then we comparetext-based and visual programming in general,and we describe how PWGL is positioned withinthese categories. After this, we enumerate themost important design issues that have guided ourdevelopment work. Following these introductorysections, we present the main visual components ofthe system and describe the primary principles thatallow users to manipulate a visual patch. Next, weintroduce the programming interface that allows oneto extend the system with user libraries, boxes, andmenus. This section includes a novel programminginterface that can be used to import new synthesisboxes into our synthesis environment. We givealso a short survey of the PWGL Tutorial concept,which can be used for demonstrations, pedagogicalpurposes, or for private study. We conclude with anextended PWGL example.

Related Work

Currently, PWGL is one of the three major Lisp-based composition environments, along with IR-CAM’s OpenMusic (OM; Assayag et al. 1999) andHeinrich Taube’s Common Music (CM; Taube1991). Of these systems, CM differs most fromthe other environments as it relies on text-basedprogramming and various third-party applicationsfor data visualization, sound synthesis, and mu-sic notation. PWGL and OM, by contrast, relyheavily on visual programming and contain manyaspects (boxes, music notation, visual editors,etc.) that are integrated to the kernel part of thesystem.

Like PWGL, OM is a successor of PatchWork andthus has several points in common with our system.OM includes several important extensions andimprovements compared to PatchWork, includingits persistent object system, the visual programmingof objects, the “maquette” editor, etc. Since itsintroduction during the late 1990s, OM has gained alarge user base (Agon, Assayag, and Bresson 2006).

PWGL and OM are complex environments withunique features, and thus an extended comparisonwithin this article is not feasible. We will simplynote here some of the most important differencesbetween the two systems. First, despite their obvioussimilarities inherited from the PatchWork tradition(both use patches with boxes and connections), OMand PWGL take somewhat different approaches tovisual programming. On the one hand, OM hasa tendency to emphasize the visual programmingaspect more than PWGL; for example, it providestools where CLOS classes can be created usingdialogs, where class properties such as inheritance,slots, and methods can be edited visually. PWGL,in turn, is more text-oriented, where this kindof programming is performed textually. On theother hand, PWGL has a more sophisticated visualenvironment than OM. For instance, because ourgraphics are based on OpenGL, all visual entities(windows, boxes, input boxes, and music notation)are fully scalable. (OpenGL will be discussed inmore depth later in this article.)

Second, PWGL contains a dedicated synthesisenvironment that allows one to visually create in-strument definitions, musical scores, and mappingof control information within one unified frame-work. OM, by contrast, does not contain a dedicatedsoftware synthesizer, and so control informationmust be exported to external synthesis environ-ments (Agon, Stroppa, and Assayag 2000). Finally,our music-notation environment, ENP, when com-pared to the somewhat rudimentary music-notationfacilities of OM, offers a rich notation tool inwhich scores can be produced either manually oralgorithmically. ENP has a mouse-driven graphicaluser interface, a large set of musical primitives, anextended concept of expression markings, and itallows an algorithmic control over scores.

20 Computer Music Journal

Text-Based Programming and Visual Languages

According to a definition given in Myers (1986, p. 60),“Visual Programming (VP) refers to any system thatallows the user to specify a program in a two (ormore) dimensional fashion. Conventional textuallanguages are not considered two dimensional sincethe compiler or interpreter processes it as a long, one-dimensional stream.” When discussing the benefitsof visual programming languages, Myers gives thefollowing argument on why visual languages areconsidered appealing: “The human visual systemand human visual information processing is clearlyoptimized for multi-dimensional data” (p. 60).

According to Ambler and Burnett (1989), vi-sual languages can be divided into two categories.Visually transformed languages are inherentlynon-visual but possess superimposed visual repre-sentations. Naturally visual languages, by contrast,attempt to develop entirely new programmingparadigms. The inherent natural expression of theselanguages is visual and may not have strictly textualequivalents.

As our system is built on top of CommonLisp, a text-based language, PWGL is closest toa visually transformed language, and we will usethe term “visual language” in this restricted sense.Furthermore, it is important to note that PWGLis not a purely visual language, as our system alsodepends on text-based programming.

An important aspect of the text-based program-ming languages is that there are many universallyknown standards among them—C, Java, CommonLisp, etc. Also, in cases such as complex controlstructures like loops and recursion, they are usuallymore compact than visual languages.

Among the strengths of visual languages, in turn,is the fact that the user can build the programminglogic graphically by selecting different modules(usually boxes) and by making connections amongthese. The result resembles a flow chart that is ofteneasier to read, modify, and understand than text-based programs. Also, visual languages are simplerto master as they usually have a more uniformand intuitive syntax than text-based languages.Essentially, the syntax consists of making the

“right” connections among the “right” boxes.Furthermore, many visual languages provide boxesthat are functional already before they are connectedto other boxes: the inputs contain meaningfuldefault values.

A music language can be based on any program-ming approach—text-based, visual programming, ora combination of both. In our opinion, incorporatinga visual front-end to a music language makes itmore attractive and flexible. Musical objects can berecognized and modified efficiently, and programstructures can be parsed, understood, and manipu-lated more easily. When displaying musical materialvisually onscreen, we can ideally combine the ben-efits of traditional score representations with thenovel and dynamic possibilities of the computer.However, if the system becomes overly orientedtoward visual programming, then having a visualfront-end can become counterproductive, resultingin patches that are crowded and confusing. In thesecases, the textual approach is often more economicand efficient. Thus, the user should ideally be ableto switch to whatever programming technique isappropriate to a given problem. As PWGL is closelyrelated to its base Lisp language, mixing textual andvisual programming is straightforward.

General PWGL Design Issues

There are several important cross-platform technolo-gies behind PWGL, such as Automatic Source-CodeGeneration (ASG) and OpenGL Vector Graphics. Webriefly discuss these technologies next, and then weend this section by enumerating the key conceptsbehind the graphical user interface of PWGL.

ASG is an integral part of PWGL providingsimple persistent object storage. ASG can be usedto transform virtually any Lisp object into an ASCIIrepresentation. This, in turn, can be used to producecopies of the original, or it can be saved to a file.There are several free and commercial PersistentObject Storage systems, such as William’s ObjectOriented Database (WOOD) for Macintosh CommonLisp (MCL), PCLOS (Paepcke 1990), AllegroStorefor Allegro Common Lisp (www.franz.com), Statice


for Symbolics Lisp Machines, etc. These systemsare usually implemented using CLOS’s metaobjectprotocol (Kiczales, Rivieres, and Bobrow 1991) orsome kind of database system, such as Berkeley DB(Olson and Seltzer 1999). Our CLOS-based PersistentObject Storage system was designed specifically forthe needs of PWGL. ASG enables programmers(including the original developers) and users totransparently design new objects without havingto write complicated and error-prone code to makethem reproducible.

The graphics part of PWGL is programmed usingOpenGL (Woo et al. 1999), a cross-platform appli-cation programming interface (API) for developingportable, interactive 2D and 3D graphics applica-tions. It features double-buffering, anti-aliasing, andhardware acceleration, for example, and is an in-expensive way of creating state-of-the-art graphicaloutput and user interaction. One of its most impor-tant features is its ability to interact with arbitrarycomplex graphical objects. This mechanism—called“picking”—is a powerful tool and it is used exten-sively in PWGL’s graphical user interface. Gradientcolors, transparency, and textures can be used tocreate not only appealing visual appearance butalso meaningful and functional user interface. Thisallows, for example, users to emphasize certainfactors of the workspace while keeping other aspectsin the background.

PWGL has an object-oriented graphical userinterface (GUI) that is based on direct manipulation.According to Cooper (1995), direct manipulationcan be broken down into three basic principles:(1) visual representation of the objects, (2) theuse of dragging instead of text entry or menuselection, and (3) feedback on the impact of themanipulation. Object-oriented user interface design,in turn, is a well known interface paradigm thathas several advantages, including (1) familiarityof the conceptual model, (2) seeing and pointingversus remembering and typing, (3) WYSIWYG(“what you see is what you get”), (4) universaland consistent commands, (5) simplicity, and (6)modeless interaction (Smith et al. 1982). Theunderlying idea behind PWGL GUI is to allowthe user to manipulate the information containedin the patch and its various graphical editors as

straightforwardly as possible. As a general guideline,any object of any complexity can be edited directly,and all editing operations provide synchronizedvisual feedback for the user.

According to Nielsen (1993), there are five mainattributes of usability: learnability, efficiency, mem-orability, error handling, and user satisfaction. Forexample, in PWGL, learnability and memorabilityare aided by the facts that there is only a smallnumber of mouse shortcuts and that these shortcutsbehave similarly across the application. Efficiency,on the other hand, is ensured by allowing the userto manipulate data directly in place. As PWGL is aprogramming environment, and we have chosen tofavor a more open approach (in contrast to a closedand restricted API), errors are generally left to theunderlying Lisp system for handling.

In most cases, the objects themselves act ashandles for maneuvering the data, but in certainapplications, PWGL uses the concept of additionalhandles (Nielsen 1993). PWGL also uses cursorhinting (Nielsen 1993). This is important, first,for showing the user which object can be directlymanipulated, and second, for giving hints as to thetype of the operation that can be performed. Forexample, when resizing a box, a horizontal arrowindicates that the size parameter is horizontallyconstrained, and a vertical arrow, in turn, indicatesthe size parameter is vertically constrained.

Visual Programming Components

A PWGL box is the most important component ofthe system. It is usually represented by a rectangleshowing the name of the box, an arbitrary numberof input boxes, and one or more outputs. Whenevaluated, a box reads its inputs, calls a functionor method associated with it, and finally returnsa result. Connections are used to define relationsbetween boxes. The output of a box can be connectedto the input of another box. Thus, the system worksin a manner similar to Lisp, in which functioncalls can have either constants or functions calls asarguments. When evaluated, a box returns a Lispvalue resulting from the evaluation and prints it inan output browser. (Normally, evaluation is done by


selecting a box and typing “v” from the keyboard.)PWGL—like Lisp—is an untyped language. Usually,a patch contains a “master box” that is evaluatedto calculate the final outcome of the patch. Theuser can, however, evaluate practically any box ina patch to inspect intermediate results. Often, themain interest is not in the textual output but in theside effects of the chained evaluation of the boxes inthe patch. For instance, the final and intermediateresults can be visualized using editor boxes, or thecalculation can result in changing the state of anobject.

The PWGL evaluation scheme can be calledrequest-driven. The user requests the Lisp value ofany box in a patch to be calculated. The box receivingthe request applies its Lisp function by evaluatingits inputs. If an input is connected to another box,a new request is sent to the connected box to applyits Lisp function by evaluating its inputs, and soon. Thus, the requests move upward. By contrast,the information and data in visual systems suchas Max/MSP (Puckette 1988; Zicarelli 1998) andPd (Puckette 1996) is passed downward. A schemelike the latter is sometimes called data-driven—apatch is triggered either by incoming data fromMIDI equipment or internally by a so-called bangmessage. (PWGL also supports a triggering scheme,as shown later in this article in Figure 4).

Figure 1 demonstrates the evaluation schemein PWGL and how it relates to the following Lispexpression:

(append ‘(60) (g+ 6 ‘(60 64 67)))

The main difference between these representations(textual and graphical) is that in the graphical patch,we use two Chord-Editor boxes to visualize theinput and the output of the evaluation process.

In the Lisp expression, we read the expressionfrom left to right. We first encounter a Lisp functioncalled append that takes two arguments: the firstone is the one-element list (60), and the secondargument is a new function call that must beevaluated before append can return a result. Thefunction g+, in turn, takes two arguments: 6 andthe list (60 64 67). It then adds the first argumentto each element in the list and returns the list (66

Figure 1. This PWGL patchcorresponds to the Lispexpression (append‘(60) (g+ 6 ‘(60 6467))). In both cases, a

C-major chord istransposed upward by atritone, and a middle C isappended to the result.

70 73). After g+ has returned its result, appendcan return the final result: (60 66 70 73).

The visual patch works in a similar way. We firstevaluate the Chord-Editor that is found in bottompart of the patch. (At this stage, no notes are shownyet.) Next, we follow the connection upward andencounter a box called append. The first input isthe list (60), and second input is connected to ag+ box. In the latter box, the first input is 6, andthe second input is connected to a Chord-Editorthat returns the C-major chord as a list of MIDIvalues (60 64 67). Now, the g+ box can returnthe result (66 70 73), and then the append boxcan calculate the final result (60 66 70 73) thatis shown in the bottom Chord-Editor box.

PWGL Box Overview

PWGL offers several ways to construct boxes,ranging from completely automatic to methodsthat allow the user to specify the exact type ofinput boxes, default values, and layout options.PWGL automatically supports the most commonlyused Common Lisp lambda-list keywords (i.e.,&optional, &rest, and &key). Boxes extend eitherwith one input box (&optional and &rest) orwith two input boxes (&key) at a time. Custom-made


Figure 2. Two applicationsof the enp-constructor boxto create (a) a beat objectand (b) a chord object. Theresults are seen in theScore-Editor boxes in thelower part of the figure. In

(a), the enp-constructorbox has three parameters:the beat-unit 2, therhythm list (1 1 1 1 1),and the input-pair :kindand :accelerando. Otherunspecified information,

such as pitch, is generatedautomatically by thesystem based on defaultvalues. In (b), the firstparameter consists ofMIDI pitch informationgiven as a Lisp list (60 62

65). The other parametersare given pair-wise anddeal here with twoexpressions (ff andtremolo64).

extension patterns are also possible, allowing theprogrammer to organize the input-box distributioninto meaningful groupings, where subgroups canbe shown or hidden according to the task at hand(Laurson and Kuuskankare 2003). PWGL supportsabstraction boxes that allow the user to hide patchesinside sub-windows.

PWGL also has a novel database-oriented box typethat is able to dynamically control the extension

behavior of input boxes. Here, typically the firstinput box is a menu that allows the user to choosean option that will affect the input-box types, defaultvalues, and extension patterns of successive inputboxes. This database-oriented approach is of primaryimportance, as it allows us to drastically reduce thenumber of boxes in our system. One representativedatabase-box example is enp-constructor, aspecial constructor-box that uses the ExpressiveNotation Package (see Figure 2). This box can beused to build music-notation objects in PWGL. Thefirst input box is a menu that contains a collectionof object types used in music notation (e.g., score,part, voice, measure, beat, chord, note, etc.); seethe circled inputs in Figure 2. After choosing oneoption, the box automatically adjusts its behaviorand appearance according to the current object type.Thus, a single box is capable of handling a greatvariety of different tasks, and this provides the userwith a clear and intuitive insight to the availablemusical objects and their attributes.

PWGL Input Boxes and Editors

PWGL includes a library of predefined input-boxtypes to represent numbers, lists, sliders, switches,simple menus, hierarchical menus, editable text,static text, and buttons. It has also an importantsubgroup of input boxes that are associated witheditor windows. These editor windows containcomplex objects, such as scores, chords, break-pointfunctions, Bezier functions, and sound samples. Theassociated editor can be opened in a separate window,where the data can be viewed and manipulated inmore detail. All editors support direct manipulation,which allows the user to edit the contents withsynchronized visual feedback. Two of the mostcentral editors in PWGL are the Score-Editor (shownin Figure 2) and the 2D-Editor.

The Score-Editor allows us to represent an arrayof musical material types, such as chord sequences,melodic lines, time notation (timing information isgiven in seconds), frame notation, and traditionalWestern metric notation—all within one editor.Different material types can even be mixed. Thatall of these can be integrated in one editor greatly


Figure 3. This example contains a Score-Editor box that shows the contents of the internal score in full detail.Besides note information, one can see in the Score-Editor different expression types containing break-pointfunctions and textual markings. These are used to solve a constraint-based problem. The user gives a predefinedrhythmic skeleton in the Score-Editor box as an input to our constraint-solver Multi-Score-PMC box. The task is tocalculate the pitch content of the input score according to five textual rules that are given in the text-box. (Thefigure shows only a part of them.) Two of the rules access the break-point functions that are displayed in the scoreabove the staff lines. These shapes control the overall melodic contour of the first measure. A third rule uses theexpression repetition to produce a repetition gesture in the second measure. The two remaining rules guaranteethat all pitches in the first measure belong to a given overtone scale and disallow nearby note repetitions.

simplifies the complex issue of how to process,present, and manage musical data within a visualprogramming language.

The 2D-Editor involves a similar approach. Itsupports a collection of objects that have twodimensions, such as break-point functions, soundsamples, chord sequences, Bezier functions, markers,“scrap-objects,” and so on. It also allows users tocombine and visually synchronize these objects.

The 2D-Editor can be used for a wide range of tasks,such as sound-synthesis control, visualization ofmathematical functions, compositional sketches,musical processes, and analysis results.

In contrast to several other existing visualsystems, PWGL strongly emphasizes the visualappearance of the input boxes. All editor inputboxes are able to directly draw the contents of theireditor windows on a patch level (see Figure 3). This


means that the user can have a precise overview ofthe patch and the contents of the editors withouthaving to open the respective editor windows.If necessary, this information can be zoomed orhidden by resizing the box.

User Manipulation of a Patch

As PWGL is based on the concept of direct manip-ulation, the user is typically not forced to go intoa specific state to perform some operation (such aspanning or zooming). PWGL has a mouse-drivenuser interface and requires a three-button mousewith scroll wheel.

When the mouse is moved with no buttonspressed, the cursor changes depending on what kindof object is under the mouse pointer (i.e., cursorhinting). The first button is used to select boxes,input boxes, and connections, or to move or resizethe selected boxes. When the mouse is dragged afteran input-box click, the resulting operation dependson the type of the object. For example, when aninput-box containing a number is dragged, thecurrent value can be either increased or decreased.Double-clicks are used to open an editor or dialogthat, in turn, can be used to edit the properties ofthe associated object.

PWGL provides a uniform way of handlingpan and zoom operations. Pan is accomplishedby dragging the mouse while pressing the secondbutton, and zoom is achieved with the scroll wheel.These operations are typically global, that is, theyaffect the complete contents of a patch window oran editor window. Global pan and zoom settings canbe stored in so-called “snapshots,” which allow theuser to quickly focus on some aspect of the patch.PWGL editor input boxes also support local pan andzoom, which can be accomplished with identicalmouse gestures.

The third button is used for context-sensitivepop-up menus. All objects such as windows, boxes,input boxes, and connections have dedicated pop-up menus. These pop-up menus are of centralimportance to the system, as they inform the userwhat operations are currently possible. They aredynamic. For instance, the window pop-up menushows all abstractions that are found in the current

system; a box pop-up menu can check whetherthe current box has special options, such as addingoutputs, or adding or removing inputs; and aninput-box pop-up menu might suggest that the userconnect a slider box or a text box to the current input.

Programming Interface

Besides visual patch-level programming, PWGLoffers several ways to extend the kernel of thesystem. In its simplest form, the user can add Lispcode to a patch by using one of the available text-based editors. A text-box can be used for textualdata, rules, box definitions, menu definitions, andcode. The content of the box is not evaluatedautomatically. A Lisp-code box, in turn, is normallyused only for code, and the content is compiledautomatically when a patch is loaded.

For more advanced projects, the user can employthe user-library protocol. The idea behind PWGLuser libraries is similar to the one found alreadyin PatchWork. Typically, this kind of programmingeffort requires the developer’s version of PWGL, i.e.,PWGL Binaries. PWGL provides an example user-library template that can be used as a starting pointfor future development. This template containsinstructions on how to create a load file, how toorganize the source code within the user-libraryproject, and how to create a user-library pop-upmenu. This example contains also source code forcreating basic PWGL boxes with various input-box types. Information on how to create morecomplex box examples can be found in the includedDocumentation folder.

The synthesis part of PWGL, PWGLSynth, canbe extended with user boxes in two differentways: using a development package that allowsthe user to make boxes in C++, or creating newsynthesis binaries visually via the PWGL abstractionmechanism (Norilo and Laurson 2007). The signal-processing part of PWGLSynth consists of a numberof processing elements created in C++ for greatercomputational efficiency. Visually, these elementsare connected to special synthesis boxes that looklike regular PWGL boxes except with a small Sdesignation under the lower-right corner of the box.


Figure 4. A PWGL tutorialthat demonstrates the useof PWGLSynth. DSP-boxes(boxes marked with an“S”) are used inconjunction with two2D-Editors. The upper one

contains a sound sampleused by a granularsynthesizer. The lower one,in turn, defines anenvelope for the grains.Three real-time sliders areused to control the speed,

pitch, and master volumeparameters. The patch canbe triggered either fromthe keyboard or byclicking the button labeled<<trig>> in theline-trigger box.

In the development package, all system-levelgroundwork is provided by a base class calledpwsBox. This leaves only the input/output configu-ration, signal-processing, and event responses to bedefined by the user. These behaviors can be specifiedby the means of standard C++ class inheritanceand specialization. We offer a small C++ projecttemplate that consists of a minimal box examplethat can be compiled as a Windows DLL or Mac-intosh OS X bundle that are in turn recognized bythe PWGLSynth extension loader. This allows fordistribution of individual boxes in binary format,reminiscent of the plug-in concept popular in manycurrent software packages.

In addition to writing C++ code manually, userscan take advantage of a PWGLSynth facility forvisually defining binary extensions in a PWGLpatch. In this case, the system automaticallygenerates and compiles C++ code and createsthe appropriate PWGLSynth binaries extensiondepending on the platform.

Tutorials

PWGL contains a large help facility called PWGLHelp. This package consists of an introductorytext and a tutorial, and it is found under the Helpmenu in the application menu bar. The tutorialdemonstrates how PWGL works in practice (seeFigure 4). The documents are arranged by topic,and the contents are displayed in a hierarchicalmanner in the navigation panel on the left. A topiccan contain subtopics and/or different kinds ofdocuments. When a document name is selected, thecorresponding document is opened and displayed onthe right. In their simplest form, these documentscontain plain text. The more complex documents, inturn, are patches that allow the user to experimentwith various features of PWGL. There is alsoan optional patch documentation that can bedisplayed either as a drawer on the right side ofthe window or below the navigation panel. Thepatches are fully functional—they can be evaluated


and played, boxes and connections can be added ordeleted, and so on. Saving is disabled. Currently, thetutorial consists of about 100 documents dealingwith general issues, control structures, loops,editors, scripting, constraint-based programming,and synthesis. The PWGL Help package can alsobe compiled automatically into a PDF documentthat allows users to study the documentation offlineeither in an electronic form or as a paper copy.Figure 4 shows a tutorial document of our real-timesynthesizer along with 2D-Editors, special DSPboxes, and sliders.

PWGL Example

In this final section, we provide a large-scale PWGLdemonstration that illustrates some of the poten-tial of our system in a more demanding context.Other large-scale PWGL applications have alreadybeen discussed, for example, in Laurson, Norilo,and Kuuskankare (2005). This example is inspiredby the ideas and work of Thomas Hummel, whohas developed a multimedia library of the contem-porary orchestra, called Virtual Orchestra (VO),at the Experimentalstudio der Heinrich-Strobel-Stiftung. VO includes sample banks with morethan 15,000 instrumental sounds, pictures, andgraphical materials as well as a detailed docu-mentation of all sounds. VO is commercial soft-ware, unconnected with PWGL, and it is availablefrom Forum IRCAM (www.forumnet.ircam.fr).The system has been used, for example, to simu-late the human voice with an orchestra (Hummel2005).

What is unique in this system—when comparedto other available orchestral databases—is its biastoward modern playing techniques. Furthermore,all sounds have been systematically analyzed foracoustic properties like dynamic level, spectrum,microtonality, etc. Finally, VO allows free accessto all its data consisting of AIFF sound files andASCII data files. It contains three applications (ISIS,ISIDOR, and OSIRIS) that offer tools for variouswork situations. These applications can be used fordatabase access, for orchestral chord simulation,and as a sampler.

Our implementation has similar functions butalso some unique features. We here demonstratehow we can combine features that are normallyassociated with an application (e.g., high-level datarepresentation, hidden programming details, high-quality user interface, etc.) with the openness andflexibility of our visual programming paradigm. Wewill use our box scheme so that different propertiesof our example—such as database access, searchingand/or sorting of database items, representation ofresults, sound synthesis, etc.—can be kept distinct.These entities can then be manipulated, chained,and duplicated in many different ways in a fashionthat is typically not possible in a closed application.

We divide our project into three main parts.The first part consists of accessing data fromthe database according to search criteria. This isaccomplished with the help of a box, called vo-database (see Figure 5A). The vo-database boxis an extendable box with two required inputs,pitches and instrument. Thus, users can firstconstrain the search according to a pitch list (foran input of (), then all pitches are valid) and tothe current instrument (this input is a hierarchicalmenu that contains all VO instruments).

By adding stepwise more menu inputs, users canfurther constrain the search. When menu inputsare added to the vo-database box, it respondsintelligently, because it can determine whichoptions are possible in the VO database hierarchyin a given situation. Thus, for instance, if the pitchinput is () and the instrument input bass-tuba,then the next menu input has 23 options, such as“flutter tongue,” “double tongue,” “glissando,” etc.If the user chooses from this list the option “play andsing tones higher,” then the next input will containtwo options (see Figure 5, where this last choice is“Interval double octave”). If the vo-database boxis now evaluated, it returns nine database itemsthat all share the criteria given by the vo-databasebox. These items contain, in addition to the samplepathnames, analytical information.

Next, we use in our example a sort box tosort the result according to the spectral centroidin ascending order. This part of the process canof course be replaced by any Lisp function. Thisresult is in turn given as a data input to a box called


Figure 5. A virtualorchestra patch example.In (A), the patch is used toaccess data from the VOdatabase. This result isthen sorted according tothe spectral centroid. In

(B), the patch shows aVO-Editor box, where thefirst row of inputs, buttonsand menus deal withgeneral aspects of the box.Rows 2–7 display thecurrent database item

using text-boxes,music-notation editors,and 2D-Editors. The lastrow gives a chord sequencethat is based on theovertone analysisinformation of the result.

In (C), the synth input isconnected to a synthesispatch that is used to playthe sample informationcontained in theVO-Editor.

VO-Editor, which is the second main part, (B), in ourexample. The VO-Editor is a complex box consistingof several input-box types (e.g., two Score-Editors,one Chord-Editor, and two 2D-Editors), and itacts as a placeholder of VO database items. It hasmany properties that are organized in eight rowsof input boxes according to their functionality (seeFigure 5). The VO-Editor can be used to represent andmanipulate its internal data—i.e., select the currentdatabase item, play all samples contained in the datalist as a sequence, and select the current synthesispatch, row (1); present the current item’s textualinformation, rows (2), (3), and (4); display the currentovertone analysis information as a note sequenceand as a chord using music-notation editors, row(5); display the current spectral information andthe spectral centroid in a 2D-Editor, row (6); and

display the current sound sample, row (7). Finally,row (8) gives the overtone analysis of all data itemsas a chord sequence. All music-notation editors andthe sound sample can be played by selecting therespective input and pressing the “space” key. Themusic-notation editors of the VO-Editor box have adefault pitch resolution of one-eighth tone (i.e., 25cents).

Finally, part three, (C), of our example deals withsynthesis. The last input of the first row, calledsynth, is connected to a patch that will be usedwhen samples are played by the VO-Editor box.This scheme allows the user to dynamically editany aspect of the synthesis part. We use here a basicpatch that is able to play sound samples. The patchcontains also a reverberation unit at the output.The synth-plug boxes generate symbolic control


entry points that allow the VO-Editor box to beinterfaced with the synthesis part of our system. Formore details, see Laurson, Norilo, and Kuuskankare(2005).

Conclusions

This article presented a summary of our researchand development efforts during 2002–2008. PWGLwas originally written using Macintosh CommonLisp, but it has more recently been written usingLispWorks and is now available as free softwarefor Macintosh OS X and Microsoft Windows XP. (ALinux version will be available in 2009.) PWGL isbased on many cross-platform technologies, and ourdecision to move PWGL development to LispWorkshas proven fruitful. LispWorks offers several im-portant features in terms of our application and itsdevelopment, including OpenGL bindings for vectorgraphics; a portable GUI toolkit for user interaction;a foreign-language interface for addressing low-levellanguages; robust cross-platform support; source-code compatibility across all supported platforms;royalty-free runtime distribution; and a compre-hensive development environment with GraphicalIDE, native CLOS/MOP, and an incremental nativecompiler and interpreter. In addition to a Linuxport, our plans include gathering user experiencesand developing libraries that allow PWGL to beinterfaced with other systems and protocols, such asOpen Sound Control (OSC; Wright and Freed 1997)and Sound Description Interchange Format (SDIF;Schwarz and Wright 2000).

Acknowledgments

This work was supported by the Academy of Finland(SA 105557 and SA 114116).

References

Agon, C., G. Assayag, and J. Bresson, eds. 2006. TheOM Composer’s Book.1. Paris: Editions DelatourFrance/IRCAM.

Agon, C., M. Stroppa, and G. Assayag. 2000. “High LevelMusical Control of Sound Synthesis in OpenMusic.”Proceedings of the 2000 International Computer MusicConference. San Francisco, California: InternationalComputer Music Association, pp. 332–335.

Ambler, A. L., and M. Burnett. 1989. “Influence ofVisual Technology on the Evolution of LanguageEnvironments.” Computer October:9–22.

Assayag, G., et al. 1999. “Computer Assisted Compositionat IRCAM: From PatchWork to OpenMusic.” ComputerMusic Journal 23(3):59–72.

Cooper, A. 1995. About Face: The Essentials of UserInterface Design. Foster City, California: IDG.

Hummel, T. A. 2005. “Simulation of Human Voice Timbreby Orchestration of Acoustic Music Instruments.”Proceedings of the 2005 International Computer MusicConference. San Francisco, California: InternationalComputer Music Association, pp. 495–498.

Kiczales, G., J. D. Rivieres, and D. G. Bobrow. 1991.The Art of the Metaobject Protocol. Cambridge,Massachusetts: MIT Press.

Kuuskankare, M., and M. Laurson. 2006. “Expressive No-tation Package.” Computer Music Journal 30(4):67–79.

Laurson, M. 1996. “PATCHWORK: A Visual ProgrammingLanguage and Some Musical Applications.” PhD thesis,Sibelius Academy, Helsinki.

Laurson, M., and M. Kuuskankare. 2002. “PWGL: A NovelVisual Language Based on Common Lisp, CLOS, andOpenGL.” Proceedings of the 2002 International Com-puter Music Conference. San Francisco, California: In-ternational Computer Music Association, pp. 142–145.

Laurson, M., and M. Kuuskankare. 2003. “SomeBox Design Issues in PWGL.” Proceedings of theInternational Computer Music Conference. SanFrancisco, California: International Computer MusicAssociation, pp. 271–274.

Laurson, M., and M. Kuuskankare. 2004. “PWGL Editors:2D-Editor as a Case Study.” Paper presented at Soundand Music Computing ’04, Paris, 21 October.

Laurson, M., and M. Kuuskankare. 2005. “ExtensibleConstraint Syntax Through Score Accessors.” Paperpresented at Journees d’Informatique Musicale, Paris,2 June.

Laurson, M., and M. Kuuskankare. 2006. “Recent Trendsin PWGL.” Proceedings of the International ComputerMusic Conference. New Orleans, Louisiana: Interna-tional Computer Music Association, pp. 258–261.

Laurson, M., V. Norilo, and M. Kuuskankare. 2005.“PWGLSynth: A Visual Synthesis Language for VirtualInstrument Design and Control.” Computer MusicJournal, 29(3):29–41.


Myers, B. A. 1986. “Visual Programming, Programmingby Example, and Program Visualization: A Taxonomy.”Conference Proceedings, CHI ‘86: Human Factorsin Computer Systems. New York: Association forComputing Machinery, pp. 59–66.

Nielsen, J. 1993. Usability Engineering. Boston,Massachusetts: Academic Press.

Norilo, V., and M. Laurson. 2007. “Development Tools forPWGLSynth.” Proceedings of the 2007 InternationalComputer Music Conference. San Francisco, California:International Computer Music Association, pp. 55–58.

Olson, M. K. B., and M. Seltzer. 1999. “Berkeley db.”Proceedings of the 1999 Summer Usenix TechnicalConference. Monterey, California: USENIX, pp. 42–43.

Paepcke, A. 1990. “PCLOS: Stress Testing CLOS Expe-riencing the Metaobject Protocol.” OOPSLA/ECOOP‘90: Proceedings of the European Conference onObject-Oriented Programming Systems, Languages,and Applications. New York: Association forComputing Machinery, pp. 194–211.

Puckette, M. 1988. “The Patcher.” Proceedings of the1988 International Computer Music Conference. SanFrancisco, California: International Computer MusicAssociation, pp. 420–429.

Puckette, M. 1996. “Pure Data.” Proceedings of the1996 International Computer Music Conference. San

Francisco, California: International Computer MusicAssociation, pp. 269–272.

Schwarz, D., and M. Wright. 2000. “Extensions and Appli-cations of the SDIF Sound Description Interchange For-mat.” Proceedings of the 2000 International ComputerMusic Conference. San Francisco, California: Interna-tional Computer Music Association, pp. 481–484.

Smith, D. C., et al. 1982. “Designing the STAR UserInterface.” Byte 7(4):242–282.

Steele, G. L. J. R. 1990. Common Lisp the Language, 2nded. Woburn, Massachusetts: Digital Press.

Taube, H. 1991. “Common Music: A Music CompositionLanguage in Common Lisp and CLOS.” ComputerMusic Journal 15(2):21–32.

Woo, M., et al. 1999. OpenGL Programming Guide, 3rded. Upper Saddle River, New Jersey: Addison Wesley.

Wright, M., and A. Freed. 1997. “Open Sound Control: ANew Protocol for Communicating with Sound Synthe-sizers.” Proceedings of the 1997 International Com-puter Music Conference. San Francisco, California: In-ternational Computer Music Association, pp. 101–104.

Zicarelli, D. 1998. “An Extensible Real-Time SignalProcessing Environment for Max.” Proceedings of the1998 International Computer Music Conference. SanFrancisco, California: International Computer MusicAssociation, pp. 463–466.


Overview of PWGL PDF

Documents