jwilzewske: creativity

Showing posts with label creativity. Show all posts

Wednesday, June 22, 2011

Processionals: Repetitions, Situational Minimalism, and Elgar’s ‘Pomp and Circumstance’

T he kind of learning that will define the 21st Century is not taking place in a classroom. Rather, it is happening all around us, everywhere. We call this the new culture of learning... a fluid infrastructure where everything is constantly creating and responding to change... This new type of learning process is a cultural phenomenon that underlies a large number of people’s experiences and affects them in myriad ways. It takes place without teachers, without classrooms, and it requires [virtual, networked] environments that are bounded yet provide complete freedom of action within those boundaries.”
— Douglas Thomas & John Seely Brown.

F arewell, the neighing steed and the shrill trump,
The spirit-stirring drum, th’ear-piercing fife,
The royal banner, and all quality—
Pride, pomp, and circumstance of glorious war!”
— Shakespeare, Othello, Act III, Scene III.

T here is a big challenge in shaping the performance, vamping as it must for an indeterminate length of time while the procession continues.

T he CCM Brass Quintet did an admirable job sustaining audience interest throughout, projecting every note with the necessary dignity and authority. They varied the dynamics, softer to convey an intimate feeling while still staying audible in the large arena, louder to convey more pomp and aggrandizement. They varied the instrumentation, the round timbre of lower brass to convey a magisterial attitude, the bright timbre of high brass to convey heraldic progress.

T he physical stamina required for what can be a very long performance is considerable, a gauntlet made all the more risky to run insofar as there are only five of you (or 4 at a time, if trumpets are alternating). The thing then amounts to a 20-min quartet or, in some passages, amounts to a trio or duet ordeal, depending on the arrangement.

W hen you are repeating and repeating the same short passage for 20+ minutes, there is a natural temptation to embark on small improvisations or decorate some figures a little. Somewhat like turning a word over and over in your mind until it looks nonsensical or silly, or until finally you wonder how the word was ever coined or came to be associated with the thing it names ... tangelo, tan-gelo, tan-ge-lo, tange-lo... t’angel-o.

T he CCM Brass Quintet played nice little fanfares throughout, for all of the graduates. But when graduates of the conservatory (CCM) approached the lectern, the Quintet’s fanfares mutated into ones that were longer by several ostentatious bars, with dilatory flourishes and a grand unpredictability… droll extra service, musicians proclaiming the specialness of other musicians, heh!

E stablishing a strong relationship with a faculty mentor is one of the most important factors in determining the success one achieves as a graduate student. Faculty members “know the ropes,” so to speak, and their guidance on research, and on professional and personal conduct, can be invaluable. Typically, a faculty mentor is someone whose research interests are similar to those of the student. As such, the mentor can be an excellent source for ideas and can serve as an informed reviewer of and advocate for the student’s work.

F or those who have succeeded in establishing a strong relationship with a faculty mentor, the prospect of that relationship changing—or becoming more distant—contributes to the tumult of emotions that well-up during the graduation ceremony. Well, not to worry, usually moving away and the resulting absence make the hearts grow stronger. They will remember you fondly, more fondly than when you were slaving away, nearly for free, in their face everyday.

F or those whose mentors’ neuroses aligned in perfectly perverse way with the mentees’ neuroses, graduation may feel like a long, badly-written fugue has concluded. Begin your next Prelude, ASAP, with Pomp and Circumstance marches played by brass quintet:

March No. 1 in D (1901)
March No. 2 in A minor (1901)
March No. 3 in C minor (1904)
March No. 4 in G (1907)
March No. 5 in C (1930)
March No. 6 in G minor

Elgar Chamber Music:

Romance for violin and piano, Op. 1 (1878)
Salut d’Amour for violin and piano, Op. 12 (1888)
Chanson de Nuit and Chanson de Matin for violin and piano, Op. 15 Nos. 1 and 2 (1897/1899).
Violin Sonata in E minor, Op. 82 (1918)
String Quartet in E minor, Op. 83 (1918)
Piano Quintet in A minor, Op. 84 (1918–1919)
Concert Allegro, piano, Op. 46 (1901)
Organ Sonata in G, Op. 28 ()

Tuesday, April 19, 2011

Save The Music!: Writing Refactorable Compositions and ‘Refactor’ Methods

I n my previous CMT post, I confided a genuine ‘worry’ about the perishability of computer and electroacoustic compositions. And people laugh at this.

N otwithstanding the half-jesting comment above that delights in the fact that computer/electroacoustic works may become unperformable due to technology change, and notwithstanding that some musical works are written deliberately to be topical/of-a-time/perishable. They do not aspire to 200-year or 500-year relevance. Further notwithstanding that some composers’ goal is such prolific runtime indirection and aleatorics that there is no possibility of ‘rehearsals’ in the conventional sense, only performance—and ad hoc ‘thrownness’. Notwithstanding the fact that ‘you-shoulda-been-there!’ installation art and ‘one-time happenings’ may be a legitimate aim for some.

N otwithstanding these things, it is sad that works’ performance life ends needlessly, prematurely. Sad when all that is left of them is a recording or two, and no one will ever again hear them performed ‘live’, interpreted by different performers and realized in different settings than the ones on the recordings. Sad unless the expressive intent is to make an object-lesson of senseless carnage, waste, loss.

S orry, but a major facet of the hideous perishability of present-day computer music has to do with the fact that most musicians and composers do not have—nor do they have much desire to acquire—adequate expertise in engineering and fluency in refactoring code. On the one hand they will spend decades mastering multiple instruments and acquiring skill in orchestration, but on the other hand they will not spend a moment acquiring or maintaining skills in engineering that are needed to support preserving their achievements as computer musicians and composers. Boggles my mind.

S o what kinds of software tools and environments, if any, might be adequate for composer/users who lack technical knowledge in programming and software engineering, to enable their works to be performable ‘live’ 20 or more years from now, on different hardware and software than they were composed on? Or, given that computer and electroacoustic compositions involve multiple, complex, heterogeneous embedded (pervasive, ubiquitous) and parallel computing systems, is it even realistic to think that a ready-made end-user integrated development environment (IDE) is even feasible to create—one that would effectively immunize such musicians and their compositions against the ravages of time and technology obsolescence?

M y answer, as one who has lived for 25+ years as a professional software developer in a U.S. health informatics firm whose current-generation of applications comprise more than 37 million lines of sourcecode, is “I do not think so.” I do not think that any tool can comprehensively automate the porting and refactoring, now or ever.

I nstead, I believe that composers who want their works to remain performed and performable will either (a) have to acquire some skills of a code-refactoring engineer and suck it up and spend a modest part of their creative hours doing actual refactoring work, or (b) outsource those refactoring tasks to service contractors who do have those skills.

I n the (b) case, the composer needs to be knowledgeable enough about refactoring to be able to perform quality-assurance checks, to see that the contractor has done the job right, and to be sure that the new version does accurately reproduce the aesthetic choices of the original. Regression testing!

T he “Oh, yes, it [obsolescence, no refactoring, perishing] is wonderful!” quip on the iIRCAM twitter feed (jpeg above) [backhandedly?] feeds a kind of ego-centrism and sensation-mongering. I would love to think it’s harmless snark, a carefree “Here today, gone tomorrow, fine by me!” answer. Probably, that’s all that it is.

B ut the reality is, there’s a lot of remarkable, beautiful music—the result of countless hours of effort and musicianly skill—that today is being allowed to go headlong toward oblivion, all because nobody cares enough to engineer it in such a way as to prevent that. The book links below provide some useful sources that can guide you—that can enable you to learn how to do refactoring of your own compositions to future performance platforms, or to hire somebody else to do this.

Y es, some composers, by their own choosing, will simply decline to preserve their work, or preserve it only temporarily. Sort of like Damian Hirst and his infamous shark in formaldehyde or rotting copulating cow and bull. “Posterity? Not my problem! I won’t be alive then!” That’s fine. Being a Damian Hirst is not a disgrace. Transience is even an enviable fate. I like the idea of cremation, for example. I understand the wish to become atoms, dust.

B ut if you don’t mean to be a Damian Hirst, though, then implementing your version-to-version ‘uplifts’ changes without having to manually rewrite each and every data structure and interface design requires support by another goal: Clean separation and ‘pluggable’ pattern-based interfacing. If one has a synthesis algorithm that plays a particular soundfile or patch in a certain way and with certain timing and through certain channels, then a refactoring should allow that soundfile or patch to be accurately and consistently rendered in the new configuration, through the same or equivalent channels and with the same or indistinguishably different timing and processing, without having to manually reverse-engineer and manually specify each and every detail on the new config.

A ll of this requires an ontology for mapping synonymy of synths and waveform samples and libraries and channels/layers (and modules fan-ins and fan-outs topology, and inter-platform clock timedivision-resultion, and inter-platform sampling-freq and bit-depth skew, and EQ and reverb and other processing idioms, frequencies and pitch-bends, vocoder and compander FX, attack/decay envelopes, and timing, etc.) on different configs…

M ight be done in OWL/RDF or other environments, but such ontology does not yet exist so far as I am aware. Current-generation mapping paradigms range from 2D graphical ‘wire-patching’ of Max/MSP and Pd, to primitive source-code ‘text-based patching’ as in SuperCollider or ChucK, to WorldofWarcraft (and others’) OpenGLES patching of urMus elements, to Marsyas’s Qt4-based patching.

A s things are right now, you do in-line modding of your sourcecode, encapsulating the syntactic result of your work, but not the behaviors of your work. By contrast, true refactorings capture the behaviors and port those behaviors correctly to the new platform(s), not just the syntactic synonymy.

M any refactors that I do in Java/Eclipse are manual, really tedious. There is a refactor to convert an anonymous datatype to nested, and then nested to top-level, but there is nothing to convert a top-level type to anonymous (or nested). Lots of cut-and-paste required. Ultimately, you write your own source-modifying refactors. Chaining other refactors together into a script is only a start.

T ake Max/MSP, for example. Max is a data-flow procedural programming language in which programs are called “patches” and constructed by connecting “objects” within a “patcher”, the 2D Max/MSP GUI IDE. These objects are dynamically-linked libraries, each of which may receive input (through one or more “inlets”), generate output (through “outlets”), or both. Objects pass messages from their outlets to the inlets of connected objects.

M ax/MSP supports six basic atomic data types that can be transmitted as messages from object to object: int, float, list, symbol, bang, and signal (for MSP audio connections). A number of more complex data structures exist within the program for handling numeric arrays (table data), hash tables (coll data), and XML information (pattr data). An MSP data structure (buffer~) can hold digital audio information within main memory. In addition, the Jitter package adds a scalable, multi-dimensional data structure for handling large sets of numbers for storing video and other datasets (matrix data). Max/MSP is object-oriented and involves libraries of objects that are linked and scheduled and dispatched by a patcher executive. Most objects are non-graphical, consisting only of an object’s name and a number of arguments/attributes (in essence class properties) typed into an object box. Other objects are graphical, including sliders, number boxes, dials, table editors, pull-down menus, buttons, and other objects for running the program interactively. Max/MSP/Jitter comes with hundreds of these objects in the standard package; extensions to the program are written by composers and third-party developers as Max patchers (e.g., by encapsulating some of the functionality of a patcher into a sub-program that is itself a Max patch) or as objects written in C, C++, Java, or JavaScript. And those, too, require refactoring from time to time, just like your compositions do.

Refactored DSP Pd-Max/MSP code, PullUpMembers

R efactoring can change program behavior. For example, a ‘PullUpMembers’ refactoring changes this Max DSP method that previously was encapsulated in and extends a class ... pulls it up into the class that was previously its parent: that is the example that the A-to-B refactoring above illustrates.

B ut PullUpMembers refactoring causes concurrency bugs when it mishandles the ‘synchronized’ method. When that happens, methods in the parent and child can be time-interleaved in arbitrary ways by the operating system, different from what was the case in the original composition. It messes up the sound. You don’t want that. You need to take special engineerly steps to prevent it. You can’t just ‘plug-and-play’.

M oveMethod refactor methods can cause deadlock and starvation, with mutex and lock conflicts. Other refactoring can give rise to other sorts of bugs. The up-shots of this are that (a) creating an automated-unsupervised refactoring engine for any of the current-generation computer composition IDEs and the scripts/patches they emit would be incredibly difficult and nobody has yet done it [because there’s not enough money in it to make a viable business-case], and (b) doing it auto/semi-supervised or, worse, manually is a tough slog, mitigated only by some considerable skill and fluency in the tools and coding, hence, my remark above that it ain’t gonna happen unless you become a decent engineer as well as musician.

A ny program feature without an automated test simply doesn’t exist.”
— Kent Beck, Extreme Programming Explained, p. 57.

T he video game Half-Life 2 (HL2) uses realtime sound event calls to Pd as its sound OS. Game events are sent from HL2 to the Open Sound Control (OSC) engine, which triggers the sound by Pd via the network. Pd has the sample data and the specified sound-behaviors in-memory and can be instructed to modify those in realtime (perhaps by other game events and other processing of those) without recompiling. WorldofWarcraft uses Lua and Max/MSP.

T hink about it: if composers who are writing and maintaining video game scores across multiple years’ releases and across various gaming platforms do refactorings of their compositions out of economic necessity, why not you? Is your music any less deserving of future live performances than video game music?

W ould IRCAM or conservatories with computer music curricula please add some courseware by engineers who are knowledgeable about refactoring? Save the Music!

T he secret to creativity is knowing how to hide your sources [and efficiently refactor them in perpetuum].”
— Albert Einstein, amateur violinist.

Friday, April 8, 2011

Musorgsky’s Dream Worlds: I Musici and Natasha Turovsky’s Animations

W hen Victor Hartmann, an artist, designer and sculptor, died of a heart attack in 1873, his close friend Modest Mussorgsky was devastated and slipped into a depression aggravated by his alcohol problem. Vladimir Stasov, a music critic and friend of both Mussorgsky and Hartmann, arranged an exhibit of about 400 works of the deceased artist, hoping that this tribute might relieve Mussorgsky's depression. Thanks to Stassov, Mussorgsky was inspired to create a suite of ten musical portraits for piano, but it did not achieve popularity in any form until Maurice Ravel orchestrated it in 1923. ... Two years ago, Yuli Turovsky made his own arrangement for string orchestra. Each musical portrait of the original work is based on one of Hartmann’s paintings, though the visual element has been reinterpreted in surrealistic terms by Turovsky’s daughter Natasha.”
— Robert Markow, program notes.

K nowing that most of the paintings by Victor Hartmann which inspired his friend Mussorgsky were lost, I asked Natasha to paint new pictures, pictures inspired by the music, just as the music had been inspired by the pictures. After this was done, the next idea was to make these pictures and their personages ‘dance’ with the music. In this ‘symbiotic’ form, the audience will listen as well as ‘see’ the music.”
— Yuli Turovsky.

P ossibly the best, most compelling imagery to accompany music ever, these animated paintings [mainly watercolors] by the talented artist/violinist Natasha Turovsky, daughter of I Musici’s founder, Yuli Turovsky that were projected during their performance in Kansas City tonight.

I was reminded of Guerino Mazzola’s and Stefan Müller’s work on music information retrieval (MIR), semantic matching, and visualizations of music vector-fields with his Corebounce and EspressoRUBETTE® software (2003, pp. 920ff)... a set of notes comprising a score S, a corresponding performance P, and the associated set of field vectors F.... The animations reminded me of Mazzola’s so-called ‘Inverse Performance’... how expressive shapes can be extracted from performance and can then be re-represented in other media.

M odest Musorgsky began with a combination of title and then music... It is natural that anyone listening to music probably will have images going in his or her mind. Painting these pictures simply captured some of them for me, our version of images, in a concert. I would listen thousand times to the same piece... some are inspired more by ideas, some more by actual music color... At that point, when I was doing these paintings, there was no question about [the possibility of] doing something more with a painting [an extended opportunity to amend and enhance it]. But when I was asked now to do animation, then I thought, okay, now it [conventional painting] is not enough. If I would have known in advance the details of the performance or animation production that [Yuli] had intended, probably I would have done the paintings differently; I would have made different pictures. It is okay. In animation, I thought, how to make this stand out, since this character is very small? I did maybe ten drawings of a rooster... which became all 10 into one animated rooster that moves around on the screen. It is like a ballet: this movement, you try to see how the image, how this particular part of the image corresponds to [signification in—] the music... It’s not just animation; it’s not just music: they became ‘one’.”
— Natasha Turovsky, NPR interview with Laura Spencer, 06-APR-2011.

S ocial pressures shape anybody’s personal expression, composers maybe more so than others. But while both internal and external issues imbue the composition with its material and color, meaning does not imply pathology. Handel’s ‘O, Sleep, why dost thou leave me’ doesn’t necessarily mean that Handel was an insomniac or obsessing over his sleep patterns. Writing ‘Kindertotenlieder’ wouldn’t necessarily mean that Mahler was morbidly depressed, even though this was composed to memorialize the death of a friend’s child.

S o the message sent does not necessarily define the sender. And yet, “poiesis is concerned with the individual condition of the work’s creator as a consequence of the history [of the work’s] development as well as with the role of the broader frame of the work... neither the frequency of the vibration nor the envelope of its amplitude is uniquely determined... In fact, Fourier’s Theorem only states uniqueness of the coefficients if the fundamental period is given; but the latter is not automatically inscribed: such parameters are part of poiesis... the way of making the sound, not a ‘neutral’ sound-object.” [Mazzola, p. 12]. Here we have in Yuli Turovsky’s chamber orchestral arrangements of Musorgsky’s ‘Pictures at an Exhibition’ Natasha Turovsky’s ‘inscribing’ us, just as she was herself ‘inscribed’ by this music. Truly beautiful.

B y 1871 [age 32] he was already becoming irrelevant, and he sensed this. His intensifying depression made him fair game for anyone who might seem to have an answer, and he fell under the influence of a soothsayer who turned him from a freethinker into a fervent believer... For four years he withdrew completely from Russian musical life...”
— David Brown, p. 204.

T he sync’ing of the animated montages to the orchestra’s playing was flawless, crisp, elegant. The moods of the Natasha Turovsky’s paintings (and Gäel Hollard’s choreography and digital renderings and animations of the paintings by Hollard and Marie-Josee Auclair and Jean-Philippe Traore) embody the best of atmospheric aesthetics in animated film production. The imagery powerfully evokes the fantastical hallucinations, the playfulness, the vivid dreams and nightmares, the bipolar depression, the impressionability of Musorgsky near the end of his short life—evokes his inertness leading to dependence on others to get him to act, alternating with extreme agitation. The paintings are edgy and have wonderful visual 'depth'... they are at times sweet but not sentimental. Turovsky’s brush and pen and charcoal techniques are varied, capturing and keeping the audience’s attention and lending dramatic emphasis to the sonic gestures and arc of the music—exciting yet coherent throughout the work, despite the considerable variety in technique and visual composition.

W hen many struggle to integrate light and imagery with serious music, Ms. Turovsky and Mr. Hollard, Ms. Auclair, and Mr. Traore succeed. If you wish to have an iconic example of an approach that works, combining imagery and music, this is it. Bravo!

T abaimo’s installations clearly propose a notion and position of implicated ‘spect-actorship’ for viewers, where ‘implicated’ designates simultaneous participation and immersion—physical, political, theoretical, poetic... ‘Spect-actorship’ captures our strangely split positionality of being a part of this installation—we act like, and even become, additional characters in the animated film... the work's mechanical reproduction of a double reflexivity: the reflexivity inherent in the artist’s implicit conception of the virtual image and creative evolution as animation; and the reflexivity of the animated film as an art that is endlessly fascinated by its own elastic capacity for world-making.”
— Steven Brown, p. 209.

F rom the back room the sound of plates crashing and uncorking of bottles was to be heard. Each time Musorgsky emerged, he was becoming ever more ‘tight’. After supper the concert began, where Musorgsky would appear already completely ‘plastered’, as accompanist and solo performer. He played his own compostions with amazing perfection, making a stunning impression... At this time he was suffering from frightening hallucinations so often observed in alcoholics. Leonova reported on this in her recollections.”
— Sergey Rozhdestvensky, Univ. St. Petersburg Dept. of History, passage from Keldish & Yakovlev, 1932, ‘Musorgsky k pyatidesyatoletiyu so dnya smerti’, quoted in Brown, p. 352.