Xenakis Matters

T   he Demiurge (1) creates from an intuition of Good; (2) takes disorder and friction and waste and makes it orderly and efficient, so far as is possible to do; (3) places Reason within the soul, and the cosmic soul within the cosmic body; (4) models the cosmos on the form of a generalized sentient lifeform, i.e., an animal with moral standing; (5) creates the cosmic body on principles of geometric proportionality; (6) creates the world soul out of population-level sameness and difference; (7) blends these into a durable alloy; and (8) divides the alloy into useful, value-generating harmonic intervals.”
  — Plato’s ‘Timaeus’, quoted by Eric Lewis in Kanach, p. 81.

U   nlike Schoenberg, who controls and organizes his music at the level of the individual note, Xenakis works at the level of the whole population [of all notes, taken together, as a sound-mass].”
  — Brian Kane, in Kanach, p. 97.

T he new book, ‘Xenakis Matters’, the latest in the multi-author, multi-volume series edited by Sharon Kanach and published by Pendragon, provides a superb and many-faceted view of the enduring impacts of composer-artist-architect-engineer Iannis Xenakis, who died in 2001. Sharon Kanach is Vice-President of Centre Iannis Xenakis in France and Founder and President of the Xenakis Project of the Americas of the Brook Center at CUNY. She served as Xenakis’s assistant for two decades prior to his death in 2001.

X enakis was an iconic, formative influence on me, even though I encountered him and his teaching only for a short while in 1972. Xenakis was then still on the faculty at Indiana University at Bloomington in 1972... IU with its beautiful-and-powerful-and-then-new Control Data 6600 computer, sylvan wooded paths of the campus, and its quiet, clear-flowing limestone creek so incongruous with the intensity of the University and the minds gathered there.

S pringtime 1972 was, I suppose, before many of us recognized that the Sixties were over. It was when students at the University of Minnesota were protesting the War and barricading Washington Avenue with piles of lumber set on fire, an incendiary deconstructionist action undertaken not far from the School of Architecture where I attended Xenakis’s lectures.

S pring 1972 was when my life still straddled music and engineering equally—and when Xenakis, his music, his cross-disciplinary, fusion-avid compositional methods and materials, and his talks and writings were the epitome of innovation—his compelling, unifying vision a convergence of nature, science, engineering, and art.

H is mathematical models as automatic generating functions—not only for making music but for representing it—where equations accomplished this in a manner so much more compact than mere notes on paper could ever do: so crystalline, the beauty of this.

T   he idea becomes the machine that makes the art .”
  — Sol Lewitt.

H is programmatic transformations of acoustic forms and found-sounds—embodying a mode of creativity beyond pitch and rhythm and traditional music pedagogy—a random and happenstantial process can nonetheless have statistical self-similar or fractal properties across the ensemble of parts/voices and across time, and can manifest and evoke specific, real meanings.

C   an order be established from noise? Well, your music was the first to discover this.”
  — philosopher Michel Serres, remark during Xenakis’s PhD thesis defense.

H is physicality and love of ‘immersive’ media and sonic productions—in which the raw and elemental and cranked-up challenged us to (re-)discover the boundaries between Nature and the human.

H is famous book, ‘Formalized Music’, wherein he referred to some of his work as the musical equivalent of the “phenomena of a political crowd... protesters forming a human ‘river’, and their shouted messages propagating from front to back, comprehensible to an observer situated at a distance from the crowd but often not coherent, as such, to individuals within the crowd”.

I ’ve spent the 40 years since then in very different ways than I would have imagined, most of them doing software engineering. But the maieutic* debt that I owe to Iannis Xenakis as an important teacher in my life is great. [*uncovering through analysis; eliciting knowledge by provoking or questioning; assisting-in-coming-into-being; midwifing]

I  suppose only as we get older do we really begin to appreciate/apprehend the entire cycle of Life. There is a sense of totality to life and its review, a summing-up. The emphasis is on the ‘examined life’, on how we assess our life and how we have lived it, and assess what truth we have synthesized from the events that have accumulated, from our own efforts and decisions, and from the acts of others and how they have filled and inhabited our lives.

A  powerful mixture of emotions—happy memories; regret; guilt; 40 years’ longing and loss—is part of what this book caused to well-up in me—part of what will lead me to read and re-read this volume in years to come. The poignancy of what is remembered so vividly across the decades is staggering. I become reattached to my past as it is reanimated by these authors on these pages.

S ignificant for many readers besides me, though, is how this book works as historiography—revealing how life crystallizes itself in the artifacts that remain in us, emblems of the impact that others have had on us.

I n hindsight, it’s impossible to exaggerate Iannis’s importance to my development, as a person and as an engineer. While insisting on holding students to high standards, he also took an active, personal interest in each one’s well-being. Puckish and provocative, but always seeming to accurately gauge the limits of each. Xenakis’s legendary generosity/hospitality/charity is part of his legacy and, no doubt, a major reason why he is remembered so vividly by so many people, even ones like me who only encountered him briefly.

R emembering now Iannis Xenakis’s smiling face, remembering his exuberance and enthusiasm—how he confided his uncertainties about what some of his music meant, while he simultaneously professed that each motive and pattern did have meaning(s), however ineffable those meanings may be; how he excitedly expressed his ideas and showed his students how to make them work, or, at a minimum, how to believe sufficiently in the possibility so that they fearlessly strived to make it happen—redeems me a bit from my long history of sinning by transience and forgetting.

G   enuine problems are... both necessary and impossible. Possibility arrives right when you no longer expect it. That is what an ‘event’ really is.”
  — Alain Badiou, quoted by Olga Touloumi in Kanach, p. 101.

I n summary, reminiscence can be dynamic and creative—it can be productive of new discoveries; reminiscence does not have to be reductionistic or static—and I thank Sharon Kanach and her co-authors for this gift.

A ll of the essays in ‘Xenakis Matters’ are engaging and a joy to read. Each essay advances the scholarship regarding the composer’s ideas and influence. And each conveys the kindness, humanity, and something of the humor and kindly nature that are what I remember of him. Robert Wannamaker’s chapter (pp. 127-141), especially, on math exhorts composers to emulate Xenakis’s use of ‘discretion’ in humanizing the combination of mechanical/programmatic musical elements with human ones, to achieve a synthesis that can touch the heart and move us in valuable or even life-changing ways.

M   usic is a mathematical exercise, disguised in such a way that the mind does not realize it is counting.”
  — Gottfried Wilhelm Leibniz.

I  love this book—for reasons noted above, universal as well as personal. Whether or not you have personal memories of Xenakis as an excellent human being, you will, I’m confident, love the book too.

• Les fichiers concernant Xenakis à la Bibliothèque nationale de France (BnF)
• www.iannis-xenakis.org
• Berntsen D, Rubin D, eds. Understanding Autobiographical Memory: Theories and Approaches. Cambridge Univ, 2012.
• Brown C, Liebovitch L. Fractal Analysis. Sage, 2010.
• Castelnuovo-Tedesco P. 'Reminiscence and nostalgia: The pleasure and pain of remembering,' in Course of Life: Psychoanalytic Contributions toward Understanding Personality Development. Greenspan S & Pollock G, eds. NIMH, 1980, pp. 115-27.
• Dawson R, Bynghall S. Getting Results from Crowds. 2e. AHG, 2012.
• Deutsch H. Confrontations with Myself. Norton, 1973. [meta-biography; on the psychology of examining one's life]
• DSM. How much of Xenakis's 'Morsima-Amorsima' was really computer-generated? 04-JUN-2009.
• Fox C. Iannis Xenakis: Sites & Sounds. The Guardian, 17-NOV-2011.
• Harley J. Xenakis: His Life in Music. Routledge, 2004.
• Kanach S, ed. Xenakis Matters. Pendragon, 2012.
• Losa G, et al., eds. Fractals in Biology and Medicine: Volume III. Birkhäuser Basel, 2002.
• Moss C. Interview with Carey Lovelace and Sharon Kanach regarding Xenakis. Rhizome, 13-JAN-2010.
• Nekrashevych V. Self-Similar Groups. AMS, 2005.
• Park K, Willinger W, eds. Self-Similar Network Traffic and Performance Evaluation. Wiley, 2000.
• Rubin D, ed. Autobiographical Memory. Cambridge Univ, 1988.
• Rubin D, ed. Remembering our Past: Studies in Autobiographical Memory. Cambridge Univ, 1999.
• Schacter D. The Seven Sins of Memory: How the Mind Forgets and Remembers. Mariner, 2002. [transience, blocking, misattribution, suggestibility, bias, persistence, absent=mindedness]
• Sheluhin O, Smolskiy S, Osin A. Self-Similar Processes in Telecommunications. Wiley, 2007.
• Surowiecki J. Wisdom of Crowds. Anchor, 2005.
• Xenakis I. Formalized Music. 2e. Pendragon, 2001.
• Xenakis I. Arts/Sciences: Alloys. Pendragon, 2010.
• Xenakis site at Musicportal.gr
• Xenakis page at Boosey & Hawkes

Recording of Pianist Yuji Takahasi performance of Xenakis’s ‘Herma’

I   n 1963 I became [Xenakis’s] composition student. When I showed him my piano piece, he pointed to two sections in the piece and offered me a big eraser... I can still feel the notes of ‘Herma’ at my fingertips. Performing ‘Herma’, I discovered the gravity-free state of sound. It was the feeling of lightness, rather than the violent movement other people surmise from the pianistic virtuosity of the work... I hear through those hundreds of notes—and I sense from them at unexpected moments—something like a voice of the inexplicable.”
  —  pianist Yuji Takahashi, quoted by Roger & Karen Reynolds in Kanach, p. 13.

Martin Stadtfeld: Inspired Runtime Indirection

T   he Busoni transcription is] absorbed in itself, moving round itself, decidedly turned away from the world... brooding; Beethoven-ish.”
  — Hugo Riemann.

A   lthough Bach set verses from Luther’s ‘Nun komm, der Heiden Heiland’ nine times, many of the same Advent themes run through all the settings. Subtle nuances and theological allusions point to various verses of the chorale text, and the cantatas remain a starting point for the interpretation of the organ works.”
  — Anne Leahy, in Zager, p. 95.

M artin Stadtfeld’s performance of Mendelssohn’s Klavierkonzert Nr. 1 g-Moll op. 25 with Sir Neville Marriner and Academy of St. Martin in the Fields at the Rheingau Festival was exceptional—a young man’s composition, performed with a young person’s sensibilities and energy. It simply sang!

B ut Stadtfeld’s 4’30” encore (Ferruccio Busoni’s transcription of J.S. Bach’s BWV 659 ‘Nun komm, der Heiden Heiland’) revealed a maturity and grasp of life’s setbacks and aporias: it was teleological, driving purposefully toward its goal(s) with pragmatism and propensity toward acceptance, yet with an open-heartedness/open-mindedness that still has room for hope.

S tadtfeld’s left-hand is quiet... ‘reticent’, as recommended in the performance notes in the original Breitkopf & Härtel edition of Busoni... enabling his melodic right-hand to have the terse prominence it requires. The tenuto and agogic accenting in the right-hand, in turn, conveys motives that are… pregnant.

T he expectancy was such that Stadtfeld impressed us that he himself was discovering things as he went, even though he has performed this prelude many, many times in the past... ‘sehr ausdrucksvoll mit vollem Anschlag.’ Many notes—the touch he applied to them—were, to me, like variable values in a software module that were resolved and bound at Stadtfeld’s pre-concert preparation—at ‘compile-time,’ so to say. But there were equally many that are only resolved on a moment-by-moment basis during performance (runtime). The balance between these lent a tremendous liveliness and interest and vibrancy to the performance of this beautiful Busoni transcription.

I t is, for me, analogous to the difference in software between a layered design with subroutines and an object-oriented design with event-handler methods. The terseness of the left-hand is such that Stadtfeld expresses not a human resoluteness but instead a process in Nature, something that is immutable, like mortality; not at all deterministic, but inevitable in the sense that human wishes and intentions cannot change the outcome.

I n software engineering terms, the Busoni-Bach left-hand module is a ‘wrapper’ and encapsulates the right-hand module. The left-hand ‘service’ owns a set of ‘objects’ with ‘handlers’ that share the same state. State is possible to preserve across invocations as the figures recur over the 3 pages of this transcription. It lends nicely to cooperation through message passing communication. Stadtfeld’s multiple levels of runtime indirection... reveal the extent and fate of our wishing and desiring.

E ach object has three parts: a component implementation, an export interface, and an import interface. Export and import can be modeled with runtime constructs specifically designed for component wrapping and interface adaptation, such as interception techniques for runtime resolution. The trills, for example, amount to handshake interfaces between right-hand and left-hand parts.

L iabilities of interpretations that entail generous amounts of runtime indirection include (1) variation-point management [adding and binding variants at a late moment in time implies extra work for managing and implementing variation points] and (2) predictability [a large amount of variability makes it virtually impossible to test all combinations during rehearsal]. But the merits of ‘romantic,’ liberal runtime indirection include danger, surprise, and excitement of the sort we were thrilled by on hearing Stadtfeld’s inspired performance of this Busoni-Bach ‘Nun komm’ Zugabe. A tiny encore that emotionally surpassed the gifts of the excellent, larger concerto that preceded it. Bravo!

• Martin Stadtfeld website
• Rheingau Musik Festival
• Stadtfeld M. Bach: Piano Concertos: No. 2. (Sony, 2011.)
• Ferruccio Busoni (1866-1924) transcription of J.S. Bach Orgelchoralvorspiel "Nun komm, der Heiden Heiland" BWV 659 (Come, Savior of the Gentiles) at Klavier-Noten.com
• Rösel P. Ferruccio Busoni: Klavierbearbeitungen Bach'scher Werke. (Berliner Klassic, 1994.)
• Vladimir Horowitz YouTube video of Busoni transcription of Bach BWV 659.
• Viktors Berstis YouTube video of Busoni transcription of Bach BWV 659.
• Brendel A. Ferruccio Busoni: Klavierbearbeitungen Bach'scher Werke. (Philips, 2006.)
• Lipatti D. Ferruccio Busoni: Klavierbearbeitungen Bach'scher Werke. (Regis, 2006.)
• Busoni F. J.S. Bach: Orgel-Choralvorspiele für Klavier, Heft 1. (Breitkopf & Härtel, 1898)
• Busoni F. J.S. Bach: Orgel-Choralvorspiele für Klavier, Heft 1. (Breitkopf & Härtel, 1898) at SheetMusicPlus.com
• Busoni F. J.S. Bach: Orgel-Choralvorspiele für Klavier page at IMSLP.org
• One More Level of Indirection at c2.com
• Cooper K, Torczon L. Engineering a Compiler. 2e. Morgan-Kaufmann, 2011.
• Goedicke M, et al. Design and implementation constructs for the development of flexible, component-oriented software architectures. In Proc 2nd Intl Symposium on Generative and Component-Based Software Engineering (GCSE’00), Erfurt, Germany, OCT-2000.
• Lienhard A. Dynamic Object Flow Analysis. Lulu, 2009. (p. 34)
• Spring J, et al. Reflexes: Abstractions for integrating highly-responsive tasks into Java applications. ACM Trans Embedded Comput Sys 2010;10(4):1-29.
• Zager D, ed. Music and Theology: Essays in Honor of Robin A. Leaver. Scarecrow, 2006.

M   athematics is the heart and soul of music … Without question the bar, the rhythm, the proportion of the parts of a musical work and so on must all be measured … Notes and other signs are only tools in music, the heart and soul is the good proportion of melody and harmony. It is ridiculous to say that mathematics is not the heart and soul of music.”
  — Johann Mattheson, 1743, ‘Neu eröffnete musikalische Bibliothek’ 2:54.

Tabula recompositoria: Amending/Improving Compositions Resembles Software ‘Refactoring’

W    hile composers were [in earlier Centuries] certainly able to work out music in their minds without recourse to writing, at some point the music had to assume a graphic form so that it could be preserved, transmitted, and performed. The evidence suggests that composers employed two different kinds of surfaces for writing down their music: (1) an ‘erasable tablet’ such as a slate that could be used many times and (2) paper. In the period [1450-1600 C.E.] we are considering, the pencil had not yet been invented, so writing on paper meant using pen and ink. Erasure could only be achieved by scraping the ink from the surface of the paper, often resulting in holes in the paper. Paper was therefore a ‘write-once’ medium. Despite the differences in the properties of the two kinds of writing surfaces, composers seem to have used them both in much the same way for all the written stages of a composition, from the earliest sketches to the final version.”
  —  Jessie Ann Owens, p. 74.

    [20-sec clip, Umesh Shankar et al, UC Berkeley, 2003, Mozart, K. 581, Mvt. 3, ‘Trio II’, 0.4MB MP3]

M usical sourcecode (the musical score for a composition) is not sacrosanct: we honor the text in our reading of it, but we also take advantage of the interpretive latitude that it affords.

A nd any composer/arranger performs edits upon edits, to clean-up and perfect a work over a period of days to years. Or you create new versions to suit new and different purposes. It’s matter of what software developers would call ‘emergent design’.

Y ou may want to generate a piano reduction, exploding and imploding sectional structures, changing durations and meters, moving layers, manage instrument doublings, etc. .... Johnson’s book (link at bottom of the CMT post) has a good synopsis of these use-cases for MusicXML.

A lternatively, you may want to programmatically change your orchestration and timbres/sonorities, simplify or obfuscate/complexify the rhythms and horizontal relationships, de-risk the voice-leading to make it more natural to perform or sing, change the key to address the realities with regard to black-key biomechanics on keyboards or string-change biomechanics on stringed instruments. More and more use-cases for arrangers and composers!

S uzanne Clercx was the first to document the use of ‘erasable tablets’ by composers when in 1953 she published the discovery of a slate with six staves on each side [termed a ‘tabula compositoria’, ‘cartella’, ‘palierten schiffer stein’, ‘palimpsestus compositorius’, or ‘ardoyse’, depending on the country and century]. MusicXML is simply a latter-day tabula compositoria, that’s all.

W orking as I do on software in my day-job, I am impressed that compositions are homeomorphic to today’s object-oriented software and today’s data networks, including so-called ‘cloud’ computing or ‘software-as-a-service’ (‘SaaS’). All can be complex and difficult to manage.

I  suggest that the root of these problems lies in the complexity of the control and management planes—the orchestration and voice-leading and quasi-protocols coordinating the musical parts; the software and protocols coordinating the objects and network and distributed-services elements—and particularly the way the decision logic and the distributed-systems issues are inexorably intertwined.

I  am impressed that ‘refactoring’ the functionality can improve a composition just as it can improve a piece of software. There is no great profundity or earth-shattering novelty in such a view. It is just something that naturally occurs to any person who spends her/his days working on both software and music.

I  propose three key principles:

• network-level objectives,
  
• network-wide views, and
  
• direct control

that I believe should underlie any [new/refactored] architecture, be it an object-oriented software system or a musical composition.

F ollowing these principles, I identify a design pattern that I call ‘4D’, after the architecture’s four planes: decision, dissemination, discovery, and data. A 4D architecture completely separates a network’s/composition’s decision logic from the compositional protocols and performance-practice/runtime protocols that govern the interactions among the network/musician elements.

I n creating a ‘4D’ design pattern, it’s important to remember that MusicXML score files do not represent ‘presentation-level’ primitives such as pages and staff-systems ... such details of formatting will change based on different paper and display sizes. But MusicXML does represent syntactic and semantic concepts of voices (parts) and synchronization among them, segmented into ‘movements’. In the MusicXML environment, in other words, formatting is handled separately from structure and semantics. The same applies for detailed interpretive performance information. Separate MusicXML supersets could be developed to represent individual printings and performances.

R efactoring of MusicXML can, of course, be done off-line—with generation of printed parts and score ahead of performance runtime. My MusicXML source for K.581 Mvt.3 Trio II is here. This (and several Beethoven string quartets) is what I have been testing my prototype MusicXML refactoring engine with this week.

O r the refactoring of MusicXML can be done in realtime—with refactored parts rendered with streaming MusicXML interpreter to be sight-read by the performers, with (I suppose) considerable surprise for artists who are deeply familiar with the original texts—and for listeners as well.

T he realtime MusicXML refactoring works okay so long as the lead-time for the canonical refactoring service is at least one measure ahead of where the musicians are playing. That, to me, seems to be about the minimum for proper scansion and so that phrasing and other effects are not too disrupted.

O f course, this depends on the meter and tempo and the prevailing complexity—things that are making cognitive demands on each performer. If a streaming realtime refactoring is too elaborate, then the aesthetics (and the fun) will undoubtedly suffer.

B eyond this, in principle I suppose one could mike each member of the ensemble and do analog-to-digital conversion of each signal—perform digital signal processing (DSP) and pattern-recognition to impute pitch and interval and rhythm and dynamics deviations from the score—and then use those imputed deviations to drive a refactoring server, to further permute the parts or effect meta-alteration of the downstream score. That’s beyond anything that I’m prepared to attempt right now, but CMT readers with enough studio gear and computational resources may be interested to try it.

K. 581 Clarinet Quintet (‘Stadler’ Quintet) [1789]

1. Allegro (A major)
   
2. Larghetto (D major)
   
3. Menuetto (A major), Trio I (A minor), Trio II (A major)
   
4. Allegretto con variazioni (A major)

T he clarinet predominates in K.581 as ‘primus inter pares’ (‘first amongst equals’) as Alfred Einstein once wrote, yet the parts’ roles are more discursive and autonomous than they would be if this were a ‘concertante’ form where the soloist rules.

M y simple experiments initially have dwelt on Mozart’s K. 581, primarily because it is straightforward and familiar. Its interpretive history and performance practice are pretty transparent and well-understood. I wondered, “What if we refactored the Trio II, to render it as an exuberant/obstinate ‘recovery’ from the A-minor Trio I of the 3rd movement?” Okay. Here’s what I get with my canonical XML parser—scanning for and phrase and repeat boundaries in the tokenized MusicXML source.


becomes  


B asically, my “light” refactoring of K.581 treats every ‘repeat’ structure as a MusicXML ‘class’. You play it through the first time as originally written—that’s the first ‘invocation’ or programmatic ‘call’ to the ‘repeat’ class method with the contents of the bars between the repeat-delimiters as an argument. When you get to the end of the first time through, the method in the ‘main’ class (call it ‘A’) bumps an ‘excursion counter’ and calls the repeat class (call it ‘B’)—with a canonical refactoring argument to dynamically alter the articulation syntax in each part, according to rules I created for my refactoring engine to use.


B ut the simple as-written MusicXML source then involves a ‘cycle’ between the ‘main’ class ‘A’ and the ‘repeat’ class ‘B’. If this were a software refactoring, generally we try to eradicate cycles, to localize and manage features and dependencies and to improve reliability and for other reasons. How about doing the same thing in MusicXML, with similar justification? Sure...


W hat my refactoring of the score does is this:

• Extract a ‘repeat interface’ BI class from class B. BI contains the methods of class B that are needed by A, to implement the articulations (or other canonical changes that propagate through the quintet’s 5 parts) that we want to be associated with the repeats. The new, refactored class B implements BI.
  
• Set all references in class A that aren’t required for object generation from B to BI.

A  simple ‘toy’ example, to be sure, but it is non-trivial—non-trivial in terms of the parser and its embedded logic, and non-trivial in terms of the expressive effects that this has.

I n the end, what we get in this example is a canonical cascading propagation of accents, tenutos, and decrescendos—explicitly amending the expressive sense of the K.581 Trio II. Cool. It works. And it suggests how we could implement other, fancier refactorings and canonical edits.


M y particular example refactoring of the MusicXML sourcecode for K.581 Trio II is directly analogous to what in the Roock-Lippert software refactoring book is called ‘dependency inversion’ or DIP (see. pp.130-43). Again, I was only exploring here what can be done with current-version MusicXML and refactoring techniques operating on music scores; I am not saying that anything wonderful has been done to K.581 with this attempt. I am only saying that it is interesting, and that it works, and that it may be of interest to you as a composer/arranger or as a music theorist. For CMT readers who are performing artists and avid users of PC-based digital music readers (like Hugh Sung or Nicholas Kitchen) maybe this stuff has interest as well.

T o me, the effort so far seems worthwhile. Yes, MusicXML is not ideal. It’s not a ‘causal encoding format’ and therefore and commands are [must be] used to encode single parts with multiple staves or multiple voices—and so on. While not ideal, MusicXML is the reigning standard that has market-share; it is the ‘bandwagon’ to jump on.

I t’s possible that these refactoring explorations will lead to new MusicXML enhancement-requests or new requirements-specifications for future versions of MusicXML. I’d welcome dialogue with you if you have observations or concerns in that regard. Please email me or comment here if you like. Thanks!

B    rian Foote suggested the name [‘speculative generality’] for a smell to which we are very sensitive. You get this smell when people say, ‘Oh, I think we need the ability to do this kind of thing someday’ and consequently specify all sorts of ‘hooks’ and special-case requirements—to handle things that aren’t in fact required. The result is often harder to understand and maintain. If all this machinery were being used, it would be worth it. But if it isn’t being used, it isn’t [worth it]. The extra machinery [to provide abstract generality] just gets in the way [of clean, effective, testable, maintainable source-code and non-defective solutions] ... Any structure or class that isn’t doing enough to pay for itself should be eliminated ...”
  —  Martin Fowler, p. 83.

• DSM. Freund: Yet Another Partita Compiler (YAPC), Refactorings Noch Nach Bach. CMT blog, 14-JAN-2008.
  
• Refactoring page at Wikipedia
  
• Martin Fowler's refactoring site
  
• TextTransformer.com
  
• OpenSeminar - Refactoring
  
• MusicXML.org (Recordare)
  
• Good M. SCOT: A score translator for Music-11. MIT EECS Dept, 1979. [history of machine-readable music syntax, back to 1960s]
  
• Anders T. Composing music by composing rules: Design & usage of a generic music constraint system. PhD Dissertation, School of Music and Sonic Arts, Queen’s Univ, Belfast, 2007. [2MB pdf]
  
• Java XMLdiff utility
  
• Java XMLdiff utility
  
• diffxml utility
  
• DeltaXML.com
  
• DiffDoc
  
• DiffDog (Altova)
  
• MusicXML DTDs
  
• Vemus API for MusicXML score annotations
  
• Bajura K. Finale for Composers. Phoebus-Apollo, 2004.
  
• Caldwell J. Editing Early Music. Oxford Univ, 1995.
  
• Cannam C. Music typesetting on Linux: The people behind LilyPond. LinuxMusician, 2006.
  
• Clercx S. D’une ardoise aux partitions du XVIe siécle. in Mélanges d’histoire et d’esthétique musicales offerts à Paul-Marie Masson. R Massé, 1955. pp. 157-70.</a>
  
• Corozine V. Arranging Music for the Real World: Classical and Commercial Aspects. Alfred, 2002.
  
• Fowler M, Beck K, Brant J, Opdyke W, Roberts D. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
  
• Johnson M. Composing with Finale. CourseTech, 2008.
  
• Kerievsky J. Refactoring to Patterns. Addison-Wesley, 2004.
  
• Lippert M, Roock S. Refactoring in Large Software Projects: Performing Complex Restructurings Successfully. Wiley, 2006.
  
• McCutcheon A. The Muse that Sings: Composers Speak about the Creative Process. Oxford Univ, 1999.
  
• Ng K, Nesi P, eds. Interactive Multimedia Music Technologies. Idea, 2007.
  
• Owens J. Composers at Work: Musical Composition 1450-1600. Oxford Univ, 1998. (Ch. 5 - Erasable tablets)

A   ndrew Monk and others at University of York in the U.K. It is useful to think about software usability problems as forming a hierarchy with each successive level in the hierarchy requiring more contextualized knowledge. By contextualized knowledge we mean knowledge about a particular user and the goals and priorities which are relevant when the problems are identified. An example of a problem at the bottom of the hierarchy is a user having difficulty in correcting typographical errors because of inadequate delete facilities. This may be a quite general problem independent of the particular user and the task being performed. An example of a problem near the top of the hierarchy is the difficulty that a user might have in understanding how to carry out a database search task on some new system. The problem arises from the user's experience with the system, with other systems and with the task it is being used for and so depends very much on the context. Such problems often have a large impact on usability. By definition, these problems require information about the user's knowledge and beliefs in order to diagnose their cause, and to recommend the changes needed. Work at University of York has attempted to develop methods which elicit increasing amounts of context-sensitive data which can be used to diagnose problems at successively higher levels of this hierarchy and have identified four diagnostic levels. At the first level are problems that can be identified from system logs recorded from unknown users during free use. An approach was developed which identifies problems by isolating redundant user input. These problems can be diagnosed with minimal user-specific or task-specific information. A second level involved the analysis of log data from users completing tasks which have been set by the evaluator of the system. When these tasks are well constrained the system evaluator can use them to gain partial information about the users’ plans and goals when problems occur. This method is not always adequate since strategic differences amongst subjects can make plans and goals difficult to infer. A third level used verbal protocol methods to elicit users’ plans and goals directly. Two methods have been used re-enactment. Re-enactment proved particularly useful for diagnosing problems that could not be diagnosed from log data alone. In this method the user and evaluator discuss problems that the user had experienced during previous sessions.

Techniques that allow for more abstraction

• Encapsulate Field - force code to access the field with getter and setter methods
  
• Generalize Type - create more general types to allow for more code sharing
  
• Replace type-checking code with State/Strategy
  
• Replace conditional with polymorphism

Techniques for breaking code apart into more logical pieces

• Extract Method, to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions
  
• Extract Class moves part of the code from an existing class into a new class

Techniques for improving names and location of code

• Move Method or Move Field - move to a more appropriate Class or source file
  
• Rename Method or Rename Field - changing the name into a new one that better reveals its purpose
  
• Pull Up - in object-oriented programming (OOP), move to a superclass
  
• Push Down - in OOP, move to a subclass
  
• Shotgun surgery - in OOP, when a single change affects many classes—all affected code is kept in a single class, so that the change is made only in one place.”

Matthew Fields: Composer. Humanist. Just-in-Time-Activist. Computer Scientist.

A    ctually, business isn’t always ‘purely Darwinian’. (Please allow me this term because we all know what I mean even if it isn’t what Darwin meant—sorry!)
  Wed, 11-MAR-2009, P. SanGregory / S. Chien
--------
Nope, stop right there. The English language provides ‘cut-throat’, ‘ruthless’, ‘merciless’, ‘relentless’, ‘callous’, ‘cold-blooded’, ‘dog-eat-dog’, ‘inexorable’, ‘iron-fisted’, and many other terms closer to your probable meaning. In contrast, 'Darwinian' selection includes selection for those who are particularly merciful towards kin and whose genes thus survive more frequently than the selfish. ‘Darwinian biology’, i.e. real biology, observes and explains patterns in nature and does not judge them. Let us stop this misuse of the term [‘Darwinian’]. It’s part of the propaganda of the worldwide anti-science [anti-intellectual] movement ... and it undermines the very civilization which affords us [musicians] our roles.”
  —  Matthew H. Fields, Society of Composers listserve, 11-MAR-2009, commenting on draconian MTSU funding cuts, eliminating ~40 non-tenured faculty positions, including ones in Music.

I t’s been some years since I met Matthew Fields, in Winter of 1996 I think, in connection with one of my visits to the Medical Center Information Technology Dept at the University of Michigan Health System in Ann Arbor. His fiery temperament was (and is) propelled by a passionate wish for the world to be a better place. I had not known back then of Matthew’s accomplishments as a composer.

B orn in 1961, Matthew was trained at Oberlin and Stanford, and received his 1991 DMA/PhD at Univ of Michigan. Among other things, he was involved with the [now-defunct] ‘Just In Time Composers of Boston’. He received first prize in the 1991 composition contest of the Ferruccio Busoni Memorial Society, honorable mention in the Harvey Gaul Composition Competition of Pittsburg New Music Ensemble (2000), second place in the composition competition of the Utah Composers Guild (2002), and was co-winner of the League-ISCM Composer’s Competition (2006). There are a couple of CD recordings of his music that have appeared.

H is chamber music compositions are pretty diverse, but I especially enjoy Matthew’s writing for cello.



    [50-sec clip, Matthew Fields, ‘Rollerchant’, 1.2MB MP3]




    [50-sec clip, Matthew Fields, ‘Progeny of Memory’, 1.2MB MP3]

A nd I particularly enjoy his frequent interactions on SCI and other composers’ websites. His remarks are always forthright, incisive, and, in general, address these issues:

• Where is composing heading? What is being written and why?
  
• How is the the art of composing approached today?
  
• What obstacles are professional and amateur composers facing in today’s society, in North America and elsewhere?

I n case you are unfamiliar with Matthew’s work, I thought I’d put up this little post with a couple of clips and links. M.H. Fields: thoughtful humanist, innovative computer scientist, progressive activist, pragmatic advocate for peace and community, committed composer-artist ... with a day-job and family.

P    erfect is the Enemy of Good.”
  —  Voltaire.

• Matthew Fields website
  
• Fields M. Univ Michigan Lectures, 1993. (hosted at cosmoedu.net).
  
• Houston Sinfonia. Matthew Fields: Sages of Chelm. (Centaur, 2004.)
  
• SocietyOfComposers.org (SCI)
  
• International Society for Contemporary Music website
  
• Cartwright J. Evolution and Human Behavior: Darwinian Perspectives on Human Nature. 2e. MIT, 2008.
  
• Roughgarden J. The Genial Gene: Deconstructing Darwinian Selfishness. Univ California, 2009.
  
• NoExtraNotes - Midwest Calendar w/ Matthew Fields performance

Zehetmair Quartet’s Schumann: Music as Reflective Code / Creating and Conserving Open-Source Karma

The Zehetmair String Quartet delivered an invigorating performance in Kansas City tonight.

• Mozart String Quartet in G Major, KV 156
  
• Hindemith String Quartet No. 4, Op. 22
  
• Schumann String Quartet No. 1 in A Minor, Op. 41
  

For entirely personal and idiosyncratic reasons, I found the Schumann Op. 41. No.1 quartet especially intriguing. There are passages in it that reminded me of a piece of software I had recently written, involving reflection and recursion in C# (.NET)—particularly the Quartet’s last movement, the Presto. My code is parallelized, to be run on a multi-CPU parallel multiprocessor in ‘sections’ that ‘rendezvous’ with each other to produce the final result. And so here I am, listening to the Zehetmairs, thrilled to notice sections of the Schumann quartet No. 1 with identical durations are treated as ‘privileged’—much in the manner that my software works—with the violins against the viola and ‘cello. The Zehetmairs’ orienting themselves physically on the stage as they did—in two parallel columns, with the cello directly facing the viola and the second violin directly facing the first violin—is what really ‘made’ the analogy to my code and how it works. As with so many compositions, there is a bias toward hierarchical and ‘nested’ structures in the piece. And there is the ‘repeat’—what programmers would call a loop or iteration. But there are also ‘reflection’ and ‘recursion’ in this quartet—phrases that invoke new instances of themselves, “passing in” new arguments whose values are set by what has gone before, and these invocations in turn invoke yet more instances/replicas. How cool!


Recursion, exemplified by calculation of N! (the factorial of a number, N) as you may remember from high-school maths, is a fundamental concept for expressing algorithms in computer science. Recursive algorithms are typically more elegant and have far more concise code than those whose flow-of-control is implemented in iterative and conditional loops. Recently K-nets and recursive structures have been receiving attention from mathematical musicologists and music theoreticians. But, as far as I’m aware, nobody up to now has looked at algorithmic recursion and reflection in Schumann’s compositions.


How did these quartets come to be? By way of history and background, in 1842 after Clara Schumann’s return home from her tour performing in Hamburg and Copenhagen, Robert composed furiously. This probably was one of the manic episodes of his bipolar disorder. He started in April and by the end of July he’d finished the three string quartets of his Opus 41. He was 32 years old.

It’s curious that Schumann, who’d never before composed a string quartet, would explode into the idiom with three all at once. It’s even odder that these quartets turned out to be his only chamber music works without piano. And why did he never return to this project? Why did he never write more string quartets?

This Op. 41 reflects Schumann’s rapid assimilation of technique and ideas from Bach’s ‘Well Tempered Klavier’. Over the course of the previous year he’d ‘inhaled’ the quartets by the Viennese composers; grasped their mechanics; understood their architecture and flow-of-control. He’d acquired the skills to be a “hacker” in a new idiom. The Quartet No. 1 is not emblematic of ‘borrowing’ as with Brahms and others but, instead, is emblematic of ‘acumen’.

In that regard, the thematic development and counterpoint in Quartet No.1, to me, bears the hallmarks of an eager “patch” contributed to a software open-source project by a ‘newbie’ who’s acquired a reasonable fluency by quietly ‘lurking’ in the project community for some months. Some of Schumann’s writing here is clearly pianistic. His usage is ‘opportunistic’, but it is not ad hoc. His style in this Quartet is ‘modest’ yet self-assured. Schumann is applying compositional techniques and gestures that he knows ‘work’, just as any [software] developer would do. He is generalizing design-patterns from his previous [software] projects. Yes, some of the writing is maybe technically awkward for the violins, as several violinist-writers have said over the years—the Scherzo maybe more so than the Presto. And maybe this alien, pianistic quality in fact conspires to create a certain hyperkinetic/kinesthetic ‘thrill’ for the violins—and for us listeners. It’s unsettling: that’s part of its meaning and charm, and undoubtedly as Schumann intended. This is the work of an adventurous developer, not some casual bricoleur.

So what? How would this resemblance, noticed only because of my own recent work in software development, shed any new light on Schumann or on this Quartet? I think it’s worth posting here because it illuminates a dimension of Schumann and his environment that may go beyond what regular biographers might have noticed. For example, any software developer does what he/she does “in community”, with the knowledge and anticipation that other developers will see and experience the code that he/she has written. So it is between composers—especially between a newbie writing her/his first composition in a particular genre and the community of established composers in that genre. And if my suggestion (that Schumann’s phrasing and pacing and compositional structures and technical fastidiousness resemble those of a modern-day software developer) has plausibility, then we should think about the “community” whose responses Schumann was anticipating. Yes, Schumann was writing these quartets in the shadow of Haydn and Mozart and Beethoven especially. And Boccherini, Cambini, Campagnola, Viotti, and Schubert, Hoffmeister, Spohr, Burgmüller, Kraus, Kramář, Gyrowetz, Hänsel, Rejcha, and Vranický, too. But maybe these quartets’ construction reflects an implicit anticipation of the reception by Mendelssohn, Chopin, Gossec, Vaňhal, Václav Pichl and Robert Volkmann and others.

Schumann in Op. 41 seems to be trying out some of the formal procedures of Beethoven’s late quartets—but with Schumann’s own original transformations. This Quartet No. 1 is no ‘homage’ as such. In fact, as Daniel Chua has suggested, maybe Schumann’s Op. 41 was conceived in somewhat the way that Beethoven’s Op. 127 was conceived—as a means to influence musical history, rather than to reflect the musical past. These Op. 41 quartets are advancing new methods of theme construction, movement structure, and quartet orchestration. Here we have Schumann (maybe like Beethoven before him) preferring, socially, to be the musical ‘hammer’ rather than the ‘anvil’.

And so it is as well with open-source software developers. Self-styled hammers they are, never content to be anvils!


More than anything, and knowing as we do that this was Schumann’s first string quartet, what we hear are “transgressive” gestures of a “newbie” to string quartet writing. As a software developer myself, I see evidence in Op. 41 that’s reminiscent of an intense young software developer, one who is new to a particular tool-set and new project architecture / design patterns. To me, this is Schumann bursting in upon the composerly society of quartet writing, much in the manner of a developer making her/his first contribution to an open-source collaboration, such as SourceForge.

R ule 1: Stick to your level of Karma. Open-source is not a democracy. You have heard something different? This is wrong. Always keep in mind: Open-source is not a democracy. Every developer has a certain unexpressed and inexpressable level of Karma, which allows him/her to decide (or even dictate) things and to make use of the infrastructure of the community (like their version control system, their servers, etc.). Think of Karma like your “points level” in a role-playing computer game. The more levels you’ve played and the more riddles you’ve solved, the higher your Karma level grows. But beware: your Karma may be damaged or lost, if you act improperly. If you are new to a community, your Karma level is zero by default. Always keep that in mind. What is Karma? Karma basically means the trust the community has in you. It is not possible to measure Karma or even to guess it. If you have to ask, you’ll never know.”
  —  Tobias Schlitt, 10 Golden Rules for Open-Source, 19-APR-2007

After this No. 1 fugato Andante espressivo opens in A minor, we get what sounds like a second theme in the relative major. But this turns out in fact to be a first theme: the A-minor section was just a slow introduction. The movement never returns to A minor but instead finishes in F major.

The Adagio is basically a Lied in F major, and the F major evokes further uncertainty about the quartet’s tonal center. The scherzo movement is a normal, ternary form with a contrasting Intermezzo.


The vigorous Presto in A minor closes the quartet. This is the movement that immediately reminded me of my application in C# (.NET).


Schumann iterates a rising-fifth motive. He sets up so-called Kreutzer exercise figurations (Rodolphe Kreutzer’s violin etudes, designed to strengthen the violinist’s left hand) that are not just repetitive iterations but recursive—each successive instance appears to invoke yet more instantiations of the figure, in a cascade inward. The cascades alternate between the violins and the viola and ‘cello. Programmerly recursion! Not whole phrases, but smaller-scale movements within the phrases.




    [ 60-sec clip, Zehetmair Quartet, Schumann Op. 41, No 1, Presto, 2MB MP3]

Have a look at Scott Murphy’s recent article in Music Theory Online, to read a discussion of recursive regimes, Klumpenhouwer Networks, and other mathematical structure in Bartók and other classical music composers’ work. Have a look at Roger Reynolds’ book ‘Form & Method’ for more.

What about Schumann’s personality? How might that have affected what we hear in these quartets?

Provided that extensive rework doesn’t plaster over the original features, isn’t a person’s exploration of writing in a genre that is unfamiliar likeliest to reveal the inner life of that person? I suspect the answer is yes. After all, aren’t ‘first novels’ inherently first-novel-esque?

So. If we’re going to indulge in speculation about Schumann, let’s not omit his well-documented bipolar disorder. Bipolar disorder, also known as manic-depressive illness, only affects about 1% of the general population. But the prevalence rises to 30% among authors, artists, and composers—Schumann among them. Johns Hopkins professor Kay Redfield Jamison’s wonderful book ‘Touched with Fire’ looks at bipolar disorder and artists, authors, and composers. By contrast, there’s a conspicuous lack of studies of the prevalence of bipolar disorder in other creative professions, such as science, engineering, and especially software engineering.

Anybody who’s a software developer and a musician has plenty of anecdotal evidence, though. Earning a living as a software developer requires feats of memory and comprehensive recollection of protean details (of syntax of dozens or hundreds of compiler, version-control, and other software development toolsets and operating systems) that are very similar to the occupational requirements for mastery and internalization of detail such as professional musicians have. This often isn’t understood by lay persons who aren’t software engineers. But it is a commonplace, to anyone involved with software or anyone whose friends or family members are engaged in these pursuits.

It’s especially so for individuals who create open-source software—who invest hundreds of hours each year doing so, for zero financial reward. Their intellectual ‘giftedness’ is what propels them to deposit the fruits of their labors into the public domain. They do not, in general, do what they do for ulterior reasons. They are, in general, aiming to create functional, beautiful things. The process of creating, the process of innovating and moving the ‘community’ forward, are sufficient internal rewards by themselves. And, for some, their Karma, here and now, is a more reasonable concept than conventional religion.

According to Karma, performing beneficent acts brings good luck, and negative or maleficent acts result in bad luck. The consequences may arise immediately or they may be delayed. For Hindus and others, the delay can be in the present life or in the next: morally commendable acts may result in reincarnation into a higher station or class (such as a superior human or a godlike being), while bad acts result in rebirth as a human living in less desirable circumstances, or as a lower animal. Some compare the action of Karma to Western notions of sin and judgment by God or gods. Other non-deistic people understand Karma as a principle of the universe—a natural law that doesn’t require the existence or intervention of any supernatural Being.

The logical ethical consequence of the law of Karma is to behave responsibly at all times and not abuse the power that comes with virtuosity. Thomas Zehetmair and the Zehetmair Quartet are clearly creating and maintaining their good Karma. And Schumann, in his own way, may have composed these quartets—replete with fascinating recursive structures and other innovations—with the Karmic and social sensibilities that, today, are prevalent among open-source software developers as well as musicians. Just a thought.


[Sorry if you were hoping to find here an actual ‘review’ of the Zehetmair String Quartet’s performance in Kansas City. Suffice to say that their playing was, has been, and shall be spectacular. They are performing today (11-NOV) at the University of California @ Berkeley, and on 16-NOV in the ‘Music_at_MIT’ program in Cambridge, MA. In any case, go and hear them whenever and wherever you can! Buy their CDs and listen! Surely the depth and vibrancy of their interpretations will inspire unusual reveries/epiphanies as personally meaningful for you as the ones they stimulated in me. Possibly also of interest, besides Thomas Zehetmair’s commitment to this Quartet and to the classical violin repertoire, he dedicates a large part of his artistic activities to contemporary music. He’s given a number of first performances, such as the violin concerto written for him by Heinz Holliger and the violin concertos of James Dillon and Hans-Jürgen von Bose. His latest CD releases include the Ysaye Sonatas for solo violin, the Holliger Violin Concerto with the SWR Sinfonie-Orchester, and the Beethoven Triple Concerto with the Chamber Orchestra of Europe. Excellent, each and every one.]

• Zehetmair Quartet at Mariedi Anders Management
  
• Thomas Zehetmair at Askonas Holt Agency
  
• Zehetmair at ECM
  
• Reflection comp sci page on Wikipedia
  
• SourceForge.net
  
• Anglada T. Intense Minds: Through the Eyes of Young People with Bipolar Disorder. Trafford, 2006.
  
• Aubry J-M, Ferrero F, Schaad N, Bauer M. Pharmacotherapy of Bipolar Disorders. Wiley, 2007.
  
• Beaver G. The PEAR Installer. Packt, 2006. (Greg is cellist of Chiara string Quartet. His other gig is writing open-source software, managing software development projects, and writing books like this one.)
  
• Blum D. The Art of Quartet Playing: The Guarneri Quartet in Conversation with David Blum. Knopf, 1987.
  
• Burgin M. Super-Recursive Algorithms. Springer, 2004.
  
• Burkholder J, Giger A, Cox F, Birchler D, eds. Musical Borrowing: An Annotated Bibliography. Indiana Univ, 2003.
  
• Chopra S, Dexter S. Decoding Liberation: The Promise of Free and Open Source Software. Routledge, 2007.
  
• Chua D. The Galitzin Quartets of Beethoven (Opp. 127, 130, 132). Princeton Univ, 1995.
  
• Daverio J. Robert Schumann: Herald of a New Poetic Age. Oxford Univ, 1997.
  
• Deek F, McHugh J. Open Source: Technology and Policy. Cambridge Univ, 2007.
  
• Eisler E. 21st-Century String Quartets. String Letter, 2000.
  
• Feller J, Fitzgerald B, Hissam S, Lakhani K, eds. Perspectives on Free and Open Source Software. MIT, 2007.
  
• Geller B, Delbello M, eds. Bipolar Disorder in Childhood and Early Adolescence. Guilford, 2003.
  
• Goodwin F, Jamison K. Manic-Depressive Illness: Bipolar Disorders and Recurrent Depression. 2e. Oxford Univ, 2007.
  
• Griffiths P. The String Quartet: A History. Thames and Hudson, 1983.
  
• Hatten R. The Place of Intertextuality in Music Studies. American Journal of Semiotics 1985; 3/4: 69-82.
  
• Jamison K. Touched with Fire: Manic-Depressive Illness and the Artistic Temperament. Free Press, 1996.
  
• Jensen E. Schumann. Oxford Univ, 2001.
  
• Lorentz R. Recursive Algorithms. Ablex, 1994.
  
• Mannheimer Streichquartett. Volkmann: String Quartets 1 & 4. (CPO, 1994.)
  
• Mannheimer Streichquartett. Volkmann: String Quartets 2 & 5. (CPO, 1994.)
  
• Mannheimer Streichquartett. Volkmann: String Quartets 3 & 6. (CPO, 1994.)
  
• Meeker H. The Open Source Alternative: Understanding Risks and Leveraging Opportunities. Wiley, 2008.
  
• Miklowitz D. The Bipolar Disorder Survival Guide: What You and Your Family Need to Know. Guilford, 2002.
  
• Murphy S. Considering Network Recursion and Bartók’s Fourths. MTO 2007; 13(3)
  
• Ostwald P. Schumann. Northeastern Univ, 1987.
  
• Parker M. String Quartets. Routledge, 2003.
  
• Pilato C, Collins-Sussman-B, Fitzpatrick B. Version Control with Subversion: Next Generation Open Source Version Control. O'Reilly, 2008.
  
• Raymond E. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O'Reilly, 2001.
  
• Reynolds R. Form and Method: Composing Music: The Rothschild Essays. Routledge, 2007.
  
• Rounds D. The Four & the One: In Praise of String Quartets. Lost Coast, 1999.
  
• Schumann R. Letters of Robert Schumann. Library Reprints, 2001.
  
• Scott H. Indebtedness in Music. The Musical Quarterly 1927; 13: 497-509.
  
• Shapira N, Goldsmith T. Psychiatric Features of Individuals With Problematic Internet Use. Journal of Affective Disorders 2000; 57: 267-72.
  
• Soderberg J. Hacking Capitalism: The Free and Open Source Software Movement. Routledge, 2007.
  
• Steinhardt A. Indivisible by Four. Farrar, Straus Giroux, 2000.
  
• Still B, Amant K, eds. Handbook of Research on Open Source Software: Technological, Economic, and Social Perspectives. IGI, 2007.
  
• Stowell R, ed. The Cambridge Companion to the String Quartet. Cambridge Univ, 2003.
  
• Todd R, ed. Schumann and His World. Princeton Univ, 1994.
  
• Williams M. Microsoft Visual C# .NET. Microsoft, 2002.
  
• Woods D, Guliani G. Open Source for the Enterprise: Managing Risks, Reaping Rewards. O'Reilly, 2005.
  
• Worthen J. Robert Schumann: Life and Death of a Musician. Yale Univ, 2007.
  
• ArtOfTheStates.org string quartet page
  
• Sandow G. Four-Piece Orchestra, 1995.
  
• Op. 41 No. 1 score in Coda Finale / Music XML at ProjectGutenberg
  
• PatientsLikeMe.com
  
• FasterCures.org
  
• Institute for Pediatric Innovation.org
  
• ScienceCommons.org
  
• CreativeCommons.org

A man can know no greater torment than to look forward to a lifeless future of his own planning.”
  —  Robert Schumann

V ery often what we look for in the distance is so near that we need only stretch out our hand to seize it.”
  —  Robert Schumann