Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts

Tuesday, April 19, 2011

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

IRCAM tweetsI 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, PullUpMembersR 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.





Posted by at No comments:
Labels: , , , , , , , , , , , , , , , ,

Saturday, January 8, 2011

AntiPatterns: Classical Banjo, Code Refactoring, and Short Time-scale Acoustical Physics

O    ne has merely to hear the banjo’s strings touched, or one double-stop drawn out on the fiddle, to recognize the sense in which the meaning of bluegrass begins simply with what these instruments essentially are: it is the aim of bluegrass style to set forth what the instrument—or for that matter the person playing the instrument—essentially is.”
  —  Robert Cantwell, Bluegrass Breakdown, p. 203.
A  thousand kilometers away, one of my nephews is tackling learning banjo. I give him Bullard’s book (link below) and begin listening to exotic recordings by Bela Fleck and John Bullard and others, in hopes of having mutually fun dialogues with my nephew, via email and face-to-face when I go and visit him.

T he banjo sounds on these recordings remind me of the sound—the ‘interiority’, the ‘earnestness’—of traditional shamisen or samisen (三味線, literally “three-taste strings”) music. Shamisen is similar to banjo in that the dō, the skin-covered box, is a lightly-damped resonator, much like the banjo’s. Both instruments are highly percussive and relatively ‘bright’. Both are plucked with the fingers or with a plectrum.

S o I go looking around to see what spectral analysis studies have been published about banjo or shamisen. I am curious to better understand the reasons that explain the unusual tone or timbre of each. Välimäki and coworkers spent a lot of effort on the matter in the mid-1990s (link below). Unlike guitar and other stringed instruments, for banjo the 5th harmonic (fourth overtone; 2P8+M3) and higher harmonics are rapidly attenuated, except for the 8th harmonic (3P8; 3 octaves above fundamental).

S   olid body electric guitars don’t lose much string energy to the bridge. As a consequence they have a distinctive sound and are very long in sustain. Banjos on the other hand dump energy from the strings very easily to the rest of the instrument, and their characteristic sound is in large part related to that.”
  — Liutaio Mottola.
Välimäki 1996, Fig. 2
T he directionality of the instrument’s sound radiation has a lot to do with banjo-ness, too, I think. Plucked string instruments have complex sound radiation patterns for various reasons. The resonant-mode frequencies of the box account for most of the radiated sound pressure. And different mode frequencies of the body have their own directional patterns, such as monopoles, dipoles, quadrupoles, and their combinations (see examples at UNSW, Joe Wolfe’s site, link below).

A nother distinctive factor is ‘masking’ caused by occultation of the sound by (and reflections from) the performer’s body. Masking plays an important role in environments where the listener (or the recording microphones) and the sound sources are positioned off-axis from each other or are freely moving with respect to each other.

T he influence of “X” vs. “Y” hand position for passages that involve the right-hand moving up the neck of the instrument is yet another factor, one I must remember to explore with my nephew when I next see him. The “X” position lends a bright timbre, and the “Y” position gives a rounder, darker quality. What the the player does with the right-hand on the head of the banjo also changes the timbre/color a lot.

A nd then there is picking technic. Fleck’s jazz-influenced single-string picking style lends an extra “impulsion” to the banjo timbre—a consequence of sympathetic acoustic coupling to and from the other un-plucked strings? The “impulsion” is one of the qualities that I am most attracted to in these recordings.

O h, the sheer exoticness of them, though! The sound calls into question the locale, the culture and politics, and the epoch of each musical text and of each of the speakers (composer, performer) and hearers. The ‘rurality’ of banjo timbre... the instrument’s architecture preserved even in the most refined, expensive ones of modern manufacture with technical polymer engineered-composite materials and high-tech strings.

T he ‘interiority’ of chamber banjo sound is radically different from the interiority of lute or harpsichord. If our own interiority is an object, then the music embodies that ‘objective’ world. Not ‘mimesis’ or ‘representation’; more like incarnation...

P hysical strings vibrate in both the vertical and the horizontal directions (well, actually, more like a lissajous curve in the plane perpendicular to the string’s length, so the polarization directions are changing and are only intermittently orthogonal to each other). If the effective length of the string is not the same in the two predominant polarization planes, we get mixing of the subsignals of slightly different frequencies, which in turn creates beat-frequency pulsations in the sound. This is a distinctive feature not only in banjo but in the Finnish kantele’s timbre as well, where the mechanism has to do with the peculiar way in which the strings have been terminated on the box.

Lissajous pendulum
V älimäki and colleagues emphasize that distinctive timbral properties of banjo are associated with the “attack”, the early transients in the waveform in the few tens of milliseconds immediately after the string is plucked or frailed. But there are wonderful, deeply banjo-ey aspects in the notes’ “decay” as well. We hear those in the Bullard and Fleck recordings. The ‘openness’ of these transcriptions of baroque, classical, and romantic compositions affords closer examination of those timbral spectral features than would ordinarily be possible to do in, say, idiomatic bluegrass and other banjo repertoire.

I t seems to me that these recordings of Bach and other composers’ works on banjo draw our attention to what neurophysiologists call “event fusion” (the formation of unitary musical events from the micro-evolution of waveforms on a time-scale of tens of miliseconds, too small to exhibit rhythm or voice-leading) and its inter-relationships with harmony and melody and rhythm and larger-scale form.

T hese banjo transcriptions and arrangements are unusual, musically speaking, but they register for me as very familiar in other ways. ‘Refactoring’ and ‘porting’ musical “code” from one performance “platform” to another—in the manner that Bullard and Fleck exemplify—feel to me very much like refactoring and porting computer code from one computing platform/language/operating-system/architecture to another. The process calls into question the [psychological; physical] conditions necessary for making large-scale—that is, ‘formal’—interfaces and system services-stack clear in music, just as the refactoring process does in software. The process in both cases invites or even demands reconsideration of the work’s design constructs and architectural components.

I n both, it vividly reveals the different levels of abstraction that are supported or not-so-well-supported by the different platforms. And it can uncover the essence of our interior selves, by making us pay attention to neural logic-races, multi-timescale communications phenomena, and hard-coded “antiPatterns” that the composer or performer (or listener) might not otherwise have noticed. So even if the target transcribe-to platform (banjo) manifests some antiPatterns of its own, it is still always healthy and illuminating to be outside our “comfort zones” and gleaning what we can from the refactoring process.

T he beauty and elegance of these classical banjo recordings make me want to revisit some of my own code that I have recently [re-]written; improve it; maybe understand it from novel and useful perspectives.

A   ll sounds, all colours, all forms—either because of their preordained energies or because of long association—evoke indefinable and yet precise emotions, or, as I prefer to think, call down among us certain disembodied powers, whose footsteps over our hearts we call emotions.”
  — W.B. Yeats, The Symbolism of Poetry.
H   ow can we know the dancer from the dance?”
  —  W.B. Yeats.




Posted by at No comments:
Labels: , , , , , , , , , , , , , , ,

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.





Posted by at No comments:
Labels: , , , , , , , , , , , ,
Subscribe to: Posts (Atom)