Showing posts with label saas. Show all posts
Showing posts with label saas. Show all posts

Tuesday, April 28, 2009

Outer Surfaces of Seemingly-Simple Things: Lansky’s Complexity-Hiding

 Paul Lansky
I    ’m no longer comfortable with the ‘network’ model [of music structure, including synth and programmatic/aleatoric elements that are not under total human control]. There was an implicit assumption in my [earlier] topology that technology was acting as an equalizer between people... I [now] think that’s a slippery assumption. While I still think that the topology I described is interesting and suggestive, I’ve become a bit more skeptical … I regard listening to a piece of music or reading a book as an intensely interactive activity, a communication between minds. I’m a little more hesitant these days about elevating the ‘sound-giver’ too much, in that there are a lot of blurry boundaries between that node and the listener. I don’t want to regard the ‘sound-giver’ as a node with equal weight to the performer or composer. ‘Instrument builder’, however, is another matter. The design of an instrument will very often involve compositional decisions.”
  —  Paul Lansky, interview with Jeff Perry, Perspectives New Music 1995.
T  he way to make something seem simple is, often, to hide the complexity that it contains—to make a ‘black box’ out of it. (In my day-job, I am currently working on a healthcare information exchange architecture. As I do so, sometimes at night, naturally I listen to music. Inevitably, odd reveries and correspondences between composing music and writing software percolate up. Whether these are (will be—) spurious or useful, I cannot say. But to preserve the memory of them, I sometimes capture them here, in a CMT post…) [Returns to writing code, listening to Paul Lansky CD.]

F  or me, Paul Lansky is the go-to guy… a true master of complexity-hiding. Paul Lansky turns 65 in a couple of months. Once a student of George Perle… student, too, of Milton Babbitt (with whom I myself attended lectures back in the early 1980s) and Edward Cone, Paul is currently professor of composition at Princeton. He has for forty years been prominent in electroacoustic and computer music, including language development for algorithmic composition (Real-Time Cmix). [‘Enjoying’ is different from ‘revering’. I look across the room into the darkness and wonder which it is that I am feeling as the Lansky CD continues to play.]


    [Brentano Quartet, Lansky, ‘Ricercare’, 7.6MB MP3]


    [50-sec clip, Paul Lansky, ‘Idle Chatter Junior’, 2.0MB MP3]

T  he phrasing of the ‘Idle Chatter’ creates a sonic ‘surface’ that’s built-up out of microsound samples—a tonal ‘whole’ that’s astonishingly comprehensible, even if the objects out of which it’s constructed are not… The ‘Ricercar’ montage resembles—to me—the object-code output of a software object-oriented compiler, with object class hierarchies and inheritance and message-passing among instantiated class members…

I  have enjoyed Lansky’s compositions for years but now begin to try to analyze why that is—why is it that they seem to me to be so deliciously elegant? [This extraneous thought occurs to me as I examine some Java debugger output in my supposedly day-job now turned to night…]

I  should look—look under the ‘veneer’ of Lansky’s music—I must look carefully to see what complexity-hiding and abstraction methods his writing and microsound collocations implement. Maybe you will, too…

A  s with complexity-hiding methods in software in general, Paul’s musical complexity-hiding composition techniques assure that ‘users’ (performers; listeners) are not unduly burdened by issues of internal music representation or execution. To a non-programmer, deliberate complexity-hiding may seem a somewhat ‘maternal/paternal’ stance [toward the performers; toward the audience], I guess. But to a software-developer/composer, complexity-hiding is not laden with questions of asymmetrical autonomy of different parts/players. It just represents a set of ‘engineering’/‘compositional’ choices, nothing more. There are philosophically and psychologically more parallels between a software-developer and a composer than most would care to admit...

F  or example, to create a software functional specification, we make a process diagram that hides the complexity of certain parts of the operating system or services internals or end-user workflow from the developer of a particular subsystem, or hides the model-checking output from the process-modeller, or hides other things that are irrelevant to the authority and responsibility of other constituencies. To create a system technical design, we make an Application Programming Interface (API) that hides the complexity of software module internals from the system integrator and external application developers. It has been second-nature to do these things in structured software engineering for more than 30 years, but especially in the past 15. Why is it that music composition courses—even ones in computational music—neglect the applicability and relevance of these ideas to music? Probably the answers are that there are just (a) not enough people who are comfortable with and knowledgeable about the computational music software tools that have become available in the past 15 years and (b) not enough hours in the curriculum. If only they knew that inhaling that stuff could help them to make new, more novel, more beautiful, more elegant and surprising compositions! They would make more curriculum hours then, I bet…

M  y impression of ‘Ricercare’ and other pieces is that they resemble so-called ‘autonomic’ computing (see links below)—systems that are [by definition] self-configuring, self-healing, self-optimizing and self-protecting, all mostly reflexive, without extensive human deliberation but instead carried out according to pre-defined policies. The road map culminating in autonomic computing architectures encompasses the following five levels of extent or ‘maturity’:

  • Basic: The product and environment expertise resides entirely in human minds, requiring detailed rehearsal, gestures, messaging, and consultation on even routine procedures.
  • Managed: Scripting and logging tools automate routine execution and reporting. Individual specialists review information as it comes in, to make plans and decisions.
  • Predictive: Early warning flags are raised as preset thresholds are tripped. The knowledge base recommends appropriate actions. The proposed resolution of events is leveraged by a centralized storage of common occurrences and experience.
  • Adaptive: Building on the predictive capabilities, the adaptive system takes action itself based on the situation.
  • Autonomic: Autonomous algorithm-based policies drive system activities such as allocation of resources within a prioritization framework.
T  o allow system components, whether infrastructure or application software, to predict when they are on the verge of violating a threshold, ‘sensors’ must be built-in. Timers or code-instrumentation to monitor software runtime execution are built-in. [Similar monitor structures are present in the compositions of Paul Lansky—I am sure I am not crazy in inferring that they are there in these pieces I am listening to tonight.] In other words, the ‘adaptive’ maturity level of autonomic computing systems calls for the creation of a process that monitors resources, defines a systematic reaction to a set of indicators, and the automation of procedures that alleviate the underlying problem. For example, just as RAID arrays of fault-resilient disk drives can be configured to automatically ‘mirror’ a failed drive to a spare drive, members performing Lansky’s ‘Ricercare’ can be configured automatically to gracefully respond to a situation involving one member of the string quartet…

T  he automatic aspect of the response is one guideline for determining whether a given system has matured to the ‘predictive’ level or gone beyond it to become ‘adaptive’. Lansky’s music is at least ‘adaptive’; it remains an open question as to whether some of it goes yet further, into the realm of fully ‘autonomic’…

T  he threshold levels defined as part of predictive systems management are not discarded as the [software-engineering/music-composition] ‘environment’ matures. These metrics are captured and analyzed, with the resulting action expressed as ‘recommendations’ and [execution-runtime/performance-practice] ‘options’. As the [system-managers/ensemble-members] gain confidence in the ability of the ‘system’ to monitor and flag events, revised response levels are defined, and first-line ‘defense’ activities are enacted by the system. In this way, the services can be considered to be ‘maturing’ to the adaptive level of an autonomic computing system.

A  daptive’ and ‘autonomic’ levels of software systems maturity require systems’ infrastructure to be integrated, to allow ‘smart’ components to recognize when an impending challenge/risk is going to affect them, or where an escalation in technical demand puts their ‘service level agreement’ (SLA) at risk. Dare I say that the same thing inheres in serious music—serious music both composed and improvised? In software, adaptive components can take advantage of alternate infrastructure to ensure uninterrupted operation and uncompromised performance in conformity with the SLA. In music, adaptive components like Lansky’s accomplish the logical equivalent. (What I mean is, after all, are there not implicit SLAs in music? Both in good composition methods and in good performance methods?)

A  daptive tools … such as balancing the ‘least recently used’ (LRU) and ‘least frequently used’ (LFU) pages of a memory ‘cache’ or a persistent-message ‘store’ gives better performance than relying on either LRU or LFU strategy alone. It becomes possible to set policy for dynamically responding to situations as they arise. For example, where a key line of motivic development in tonal music requires more resources or more emphasis to achieve the cognitive impact intended, it might prove better to temporarily pull resources from one task to assist a higher priority task than impinge on the service levels defined for that server. Sometimes I get the feeling that Lansky’s minimalist compositions are using a combined LRU-LFU regime to communicate as much as he does, using only relatively modest materials…

  • Problem management
  • System/motif availability
  • Security
  • Performance and dynamic/adaptive capacity management
T  opology hiding: It is possible to hide (e.g. encrypt or mask) information when ‘domain borders’ (administrative or technological or semantic/expressive) are crossed. Hiding of rhythmic or flow-of-control detailed information is different from hiding structural or topological information. Topology hiding is something Lansky does very elegantly, especially in his sampled montage works…

I  f a software hacker wants to attack an enemy ‘target’, the target usually must be visible or exposed. To defend a target, you need to obscure it from public view, obscure it from hackers and would-be intruders. By hiding an object, you reduce the attack ‘surface’. In computers, only the part of a progam that is accessible to an attacker can be a target of attack. The pieces of code that’re exposed to public view are usually called APIs (Application Programming Interfaces). The ‘attack surface’ is the union of the code, the interfaces, the services, the protocols, and the processes that are exposed to the system’s users. In software security design, you analyze the attack surface and minimize that surface, sometimes by putting a ‘wrapper’ around it, or placing it in a ‘package’ such that only those entities who have access to the package are exposed to the variables that are within the scope of that package. I think I hear more correspondences—between what Lansky is doing acoustically, and what I am doing writing this Java code here on this laptop…

  • Is this feature really necessary [in this string quartet movement]? If no, it should be hidden by default.
  • Is it necessary to offer this feature remotely? If yes, then determine what locations it needs to be accessed from and via what media.
  • Which users or user-types have ‘need-to-know’ justification for accessing this feature? [The viola? The cello?] Legitimacy of usership needs to be authenticated.
  • What privileges are required to use this feature? If it needs elevated privilege, how long [How many bars?] does the elevated privilege or access persist before it needs to be renewed?
V  irtualization’ is a term that I think deserves to cross-pollinate to music theory and composition, from computer engineering. In computer science, ‘virtualization’ is a design philosophy where the operating environment abstracts the resources involved in its realization. Much virtualization involves abstraction through isolation and ‘hiding’. It’s not only a way to hide the fact that resources/possibilities are limited, but also a way to hide the fact that resources/possibilities may be arbitrarily large, far greater than what is apparent in minimalist evidence from what's happening in the current performance.

N  on-disclosure cuts both ways: withholding details may create a credible impression of scarcity, or it may foster an impression that resources may be boundless.

H  olger Schmidt’s paper in the Massacci-Redwine-Zannone book (link below) addresses encryption accomplished by a combination of ‘relational renaming’ and ‘hiding’. Disclosures not only happen by way of a process that unfolds publicly; they can also happen via a process’s failing to unfold because of deadlocks, livelocks, or balking, where the failures can imply information about the respondent—especially revealing the limits of virtuosic technical capacity. So Schmidt develops a pattern-based method for encryption that protects against unwanted disclosures, including preventing disclosures through slips or failures. Analogous phenomena (deadlocks, etc.) occur in music—in the score [deliberately], not just [inadvertently] in performance. [Decides to play around with that sometime in the future, in my own composing…]

I  n music composition as in computing infrastructure, I look to RT-Cmix and Rubato and PWGL and other algorithmic composition software tools to mature along autonomic computing lines, including the ability to predict and adapt can ensure that the most important systems/motifs are ‘up and running’. Complexity-hiding in Paul Lansky’s writing: great examples to learn from and excellent use-cases to drive software requirements specs for autonomic composition software. Thank you for your interest/indulgence during the foregoing—computer/music fusion reverie with an uncertain [but decidedly autonomic] future.





Tuesday, March 10, 2009

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

 James Tenney
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