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

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.

• Paul Lansky page at Princeton
  
• Perry J. The inner voices of simple things: A conversation with Paul Lansky. Perspectives New Music 1995; 34:40-61.
  
• Brentano String Quartet website
  
• Bel B, Vecchione B. Computational musicology. Computer Humanities 1993; 27:1-5.
  
• Cope E. Virtual Music: Computer Synthesis of Musical Style. MIT, 2004.
  
• Cope D. Computer Analysis of Musical Style. Oxford Univ, 1991.
  
• Dibben N. The cognitive reality of hierarchical structure in tonal and atonal music. Music Perception 1994; 12:1-25.
  
• Longuet-Higgins H, Steedman M. On the interpretation of Bach. Machine Intelligence 1971; 6:221-41.
  
• Marsden A, Pople A. Computer Representations and Models in Music. Academic, 1992.
  
• Massacci F, Redwine S, Zannone N, eds. Engineering Secure Software and Systems: First International Symposium, ESSoS 2009 Leuven, Belgium. Springer, 2009.
  
• Miller D. Going with the grain: Granular synthesis. Electronic Musician 01-OCT-2008.
  
• Narmour E. The Analysis and Cognition of Melodic Complexity. Univ Chicago, 1992.
  
• Overill R. On the combinatorial complexity of fuzzy pattern matching in music analysis. Computers Humanities 1993; 27:105-10.
  
• Talukder A, Chaitanya M. Architecting Secure Software Systems. Auerbach, 2008.
  
• Todd P, Loy D. Music and Connectionism. MIT, 1991.
  
• Wallin N. Biomusicology. Pendragon, 1991.
  
• Virtualization page at Wikipedia
  
• Autonomic computing page at Wikipedia
  
• Intl J Autonomic Computing
  
• IBM autonomic page
  
• ACE autonomic SDK
  
• SARDES JADE-based autonomic system