jwilzewske: canonical

Showing posts with label canonical. Show all posts

Sunday, March 15, 2009

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]

Allegro (A major)
Larghetto (D major)
Menuetto (A major), Trio I (A minor), Trio II (A major)
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...

DSM – removing cycles with dependency-inversion DIP

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.

Mozart K.581 Mvt.3 Trio II, mm. 1-12 repeat, after canonical XML mark-up with accents, tenutos, diminuendos

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.

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.”

Saturday, March 14, 2009

Richard Egarr and Academy of Ancient Music’s Brandenburgs: Once and Future Youth

W e have heard these popular concertos many times, though never with as much clarity or joie de vivre as the Academy of Ancient Music's expert, one-to-a-part reading, where every line and timbre is as distinct and perfectly balanced as it must have been in the composer's imagination.”
— Elissa Poole, The Globe and Mail (Toronto), commenting on AAM’s just-released recording of the Brandenburges on Harmonia Mundi.

T he Academy of Ancient Music’s gave a phenomenal performance of the Brandenburg Concertos last night in Kansas City, one of the stops on their U.S. tour. Richard Egarr, the group’s current director, has won enthusiastic praise from critics and audiences. The sold-out audience in K.C. surely agreed.

T he inscription of 24-MAR-1721 on the dedication manuscript to Chistian Ludwig, the Margrave of Brandenburg-Schwedt, is the nominal date of composition. But most likely the Brandenburgs had been written earlier, over the span of Bach’s service as Kapellmeister at Köthen. Some think they are even earlier, maybe 1708 to 1715—when Bach was in his 20s. These are, as Egarr told us last night, “really youthful pieces”, composed in the midst of ‘Vivaldi Fever’.

T he one that intrigued me most last night was the #6: Concerto 6to à due Viole da Braccio, due Viole da Gamba, Violoncello, Violone e Cembalo (Allegro; Adagio ma non troppo; Allegro), scored for two violas da braccio, two violas da gamba, cello, violone, and harpsichord.

T he lack of violins is itself unusual. Viola da braccio is specifically a ‘modern’ viola, not the older viola da gamba. And the #6 is thought to be the oldest one—the one Bach composed when he was the youngest.

O ther theories hold that, since the viola da braccio was typically played by servants or others of lower social standing (‘pick-up’ ensembles), Bach’s intent was a political/desultory one—to thumb his nose at the musical establishment by giving a lead part to a then-supposedly inferior instrument and its players. He wanted to piss-off Prince Leopold? He was trying to get himself ‘fired’?

T he two violas start the first movement with parts in close canon. Then we get developments where the parts are seduced into melodic inventions. The two violas da gamba keep quiet in the second movement, creating a back-handed quasi-trio sonata for the two violas and continuo. “Young whipper-snappers.”

I n the third movement of the No. 6, the spirit of the gigue underlies everything, but it’s not motoric and ebullient like other of the concertos.

T he texture of the No. 6 is dark, especially in the first two movements. Surprisingly dark, despite the ‘one-instrument-per-part’ orchestration that AAM maintains—and the openness of the articulation that is associated with this orchestration.

B -flat major, yes, but the timbre has a ‘twenty-something’ darkness/brooding/melancholiness about it—yet without petulance or moroseness or narcissism.

N ice to see the whipper-snapper violas switching back and forth and swapping parts in the No. 6. We can’t hear that exchange on recordings—especially ones where the violas maintain nearly identical tone and bowing style—but with AAM the visual effect on-stage is amusing. It’s like some Noel Coward farce—the rapscallious violas getting away with a trick—obfuscating their identities; each one taking turns masquerading/impersonating the other.

Bach - Brandenburg Concertos

Concerto No. 1 in F major, BWV 1046a
Concerto No. 6 in B-flat major, BWV 1051
Concerto No. 2 in F major, BWV 1047
Concerto No. 5 in D major, BWV 1050a
Concerto No. 3 in G major, BWV 1048
Concerto No. 4 in G major, BWV 1049

B ravo! (By the way, the valveless Baroque trumpet on the #2 was the best I have ever heard, ever. Pyrotechnical-yet-tasteful, if that’s possible. Who is this guy?!?! The program-notes don’t say, nor does the AAM website! Arrggh. David Blackadder, I think. The wizardry of Egarr’s harpsichord solo in #5, also easily the most masterful I’ve ever heard. Jump for (youthful) joy! Faster! Higher!)

Academy of Ancient Music, Brandenburg No. 2 trumpet solo

Tuesday, March 10, 2009

Canonical Form as Social Networking (Reply re: Canonical Form as Epidemic Contagion)

Y our infectious/epidemiology model may be the first theory of canonical form that says that voices engaged in canon are passive ... coerced, so to say. As though the neighboring parts had some sort of apraxia until infected. But they are not at a loss for words. They are not passive [respondents]. And you obviously do not have anything like the release of tension, which is the conclusion of normal classical music composition structure.”
— Anonymous email to CMT.

I agree with some of the emailer’s observations about the earlier CMT post: the players are not ‘passive’ or ‘inert’. Each is receptive to stimulation and, after being stimulated/infected by those around them, engages in ‘speculative’ or ‘expansive’ elaboration upon what they’ve received.

B ut I disagree about the ‘tension’ point. There’s no ‘law’ that says that all musical events must be deliberative or rational or intended. Individual players may emit sounds that have unintended [but wonderful—] consequences or inadvertent meanings. Players have a possibility for automatic or pre-conscious improvisational sonic production, which the composer can call upon if she/he wishes (think Stockhausen or Nancarrow or Tenney). There may be hyper-structural or obsessive features that are far from ‘rational’ (think Feldman or Babbitt or Cage). Stochastic/random elements don't mean that a piece defies analysis—only that the analytical approach has to change to address the content. It’s not a music theory dead-end.

I n fact, I think that the indeterminacy/stochastic elements tend to make the music more ‘listener-centric’ rather than ‘performer-centric’ or ‘text/composer-centric’. We are on ‘edge’ in part because of the greater indeterminacy/unpredictability that it has, compared to conventional forms. The indeterminacy itself is a kind of ‘structure’ or ‘form’. And, so long as the player or listener understands the relationships of the structures and mechanics of the thing—how the stochastic events and mechanisms fulfill the roles of themes and modulations in traditional music—then the thing can be comprehensible and emotionally accessible, just as any other piece of music is.

I suggest that Ferneyhough’s ‘Chûte d’Icare’ and other recent compositions that employ canonical structures actually do permit significant run-time indirection. Furthermore, I suggest that such compositions are analogous to social networking and micro-blogging service. Canonical-form compositions like these are neither more nor less coercive than contemporary Web 2.0 apps and the canonical exchanges that arise in those.

Y es, canonical forms are inherently replicative. This cuts out a lot of the ‘me-too’ chatter and dilatory utterances among the parts, by definition. But there is nonetheless a lot of within- and between-channel complexity. The entropy of the signals is high, even though the signals are canonically structured! And in the Ferneyhough—or in, say, James Tenney’s ‘Postal Pieces’—the parts have to decide whether to ‘resist’ or instead ‘give in’/’succumb’ to the neighboring canonical utterances/viruses. There is the text of the score, and then there is each performer’s free-will...

C learspace uses an unconventional, passive ‘friending’ model. Other users can assert themselves as your friends with or without requiring or permitting your active assent or declining. Your only choice is to remove them (socially awkward), when all you maybe want to do is clear up your “activity feeds” so that you don’t have to drink from such a big fire-hose of information when all those people who friended you generate activity that doesn’t interest you. Facebook and other social networking apps have active/consensual assent-or-decline friending—so filtering/throttling the fire-hose is easier. In the Facebook and other active-friending apps, reciprocal friending is expected, and friend relationships are hard to break. By contrast, in Twitter the ‘following’ relationship comes without connotations of friendship (and less hesitation about unfollowing to control your attention).

W hat would be useful would be if canonical-form compositions were written like Twitter—and offered the notion of ‘following’ a part as an alternative to ‘friending’ or passively ‘subscribing’ as in conventional canonical-form compositions. That way each performer could retain some autonomous control of her/his social filter without having to ignoring feeds or corrupting the composer’s text with individual expressions/interpretations or out-of-band [a-canonical] irruptions.

Y ou can get around this by subscribing separately to each person’s activity RSS feed, but I have found no way to easily aggregate those into a single ‘river of activity’ stream other than creating a combined folder in my feed reader. By contrast, the ‘broadcast’ nature of sound means that we automatically aggregate the acoustic feeds of the other parts around us. (With my chronic hearing loss, I just have a hard time hearing the harpsichord...)

I suppose a non-broadcast canon could be composed and performed. Actually, tape loops and other electroacoustic media are in that vein. Or we could update Tenney’s postcards, and compose a canon where each performer goes into the studio alone and lays down a single track: each person/part is entirely at liberty to listen or not listen to a headphone ‘mix’ of one or some or all of the tracks that have been recorded by other performers. Then the engineer/producer/composer do the edit and post-production. Still canonical form—only off-line!

T witter itself is a great social filter. It has ‘lower friction’ than blogging, and the 140-character limit per tweet makes it less cognitively intrusive/absorptive than blogging or RSS feeds. It’s a shared party-line, and users tend to tweet things that preserve the signal-to-noise ratio for everybody on the party-line. (If they don’t, they can be un-followed without any concern.) Like blogging, Twitter allows you to time-shift your participation (something you can’t do with IM). And like ‘Chûte d’Icare’ or ‘Postal Pieces’, it permits stochastic run-time indirection.

A bout 20% of my Twitter followers are people I know. For better and worse, the rest are a wonderfully-varied ... canonical, stochastic ... Fire-Hose...

H ow does it feel to perform ‘Chûte d’Icare’ or ‘Postal Pieces’, I wonder?

T hank you for the email, and for the privilege of exchanging ideas about these things here!

I think of ‘form’ on a larger temporal scale—as what’s called ‘content’ on a smaller scale. That old ‘form-content’ dichotomy is, to me, a spurious one, because they involve the same thing at different hierarchical levels of perception. What we take to be substance or content—say, a string quartet—is really the result of forms—formal shapes and structures at a microscopic level: particular envelopes, waveforms, and sequences of these—detailsin the signal. All ‘form’ is just the same thing at a larger level,involving spans of time over, say, five minutes or more.”
— James Tenney, interview with composer Gayle Young, 1978.

Stravinsky, ‘Threni’, virulent tenor infector and susceptible bass, minor 6th below, canonically making and breaking the score’s rules

Wednesday, March 4, 2009

Ferneyhough’s ‘Chûte d’Icare’: Inter-Part Contagion

Brian Ferneyhough, photo © Regine Koerner

A previous CMT post about inter-part communication and diffusion phenomena between parts caused one reader to ask whether I’d ever looked at Brian Ferneyhough’s ‘Chûte d’Icare’, a 10-minute septet (clarinet, flute, oboe, vibraphone/marimba, piano, violin, and cello) composed in 1987-88. It’s a fascinating and, to me, beautiful piece…

[50-sec clip, Nieuw Ensemble, Brian Ferneyhough, ‘Chûte d’Icare’, 1.6MB MP3]

E ach individual part ‘clings’ for a time to its idiosyncratic ‘status quo’, and then it decamps for elsewhere, perturbed by utterances emitted by its neighbors. There is a threshold of temporal and spatial ‘proximity’ that allows one part to affect others. If you are further away than that proximity limit, then you continue on your autonomous way. But if you are within the proximity radius, then you will likely be ‘infected’ by your neighbor(s).

T he ‘infection’ (with the expressive motif(s) emitted by adjacent part(s)) takes hold, lasts for awhile (and alters the affected part’s own utterances), and then subsides. The ‘infected’ part recovers. Or, alternately, it does not recover (“mortality”) and is reincarnated with new ideas, new expressions some bars later.

H ere is a little spreadsheet that illustrates a simple 3-state “S-I-R” (susceptible-infected-recovered) simulation of epidemic spread—the sort of contagion we hear in ‘Chûte d’Icare’. You can click on the screenshot to download it and play around with it.

Spreadsheet for Susceptible-Infected-Recovered (SIR) epidemic simulation

T he point of doing simulations and mathematical analyses like these is not to get lucky and say “Aha! I get how it works!” or “The composer employed an algorithmic/formulaic tool to compose this!” Instead, the point is to be able to figure out a new gambit that could go into a composer’s toolbox, to deliberately create a visceral, real sensation of diffusion, or contagion, or some other natural process in her/his compositions—as part of a palette that can embody/represent Nature and call into question our roles in life and the cosmic [non-]scheme. Something that could be used either as an aid to composing, or as a convenience for testing and editing a work-in-progress, to confirm that the work does in fact accurately embody or emulate the intended natural process that is the subject or expressive element of the overall work. Alternatively, the point may be to help [some of us] find deeper meanings in the work, or prepare for listening/performing in such a way that we feel more at home with its expressions or patterns.

[50-sec clip, Harrie Starreveld, Brian Ferneyhough, ‘Mnemosyne’, 1.6MB MP3]