All Activity

Thank you for posting this. It would be more helpful, though, with some commentary about how you see Xenakis relating specifically to the ideas I am discussing here. Yes, Xenakis’s Formalized Music is unquestionably a foundational text in this area. I first read it in 1981, and it has remained an important point of reference for thinking about formalization, probability, stochastic processes, and the broader relationship between mathematics and musical composition. Even so, Formalized Music is not really a text for beginners, nor is it necessarily the most direct point of entry for someone encountering statistical approaches to composition for the first time. Xenakis’s thinking ranges considerably beyond relatively simple probabilistic models and develops a much larger and more ambitious conception of formalized compositional thought. Lorrain’s article in Computer Music Journal, “A Panoply of Stochastic ‘Canons’” (1980), serves a somewhat different purpose. I do not regard it simply as derivative of Xenakis. Rather, it provides a comparatively accessible introduction to probability and stochastic procedures, showing quite concretely how a family of stochastic “canons” can be understood and applied to musical thinking. It is still not exactly elementary reading, but it offers another—and in some respects more immediately practical—way into this territory. That distinction is particularly relevant to my Dynamic Event Generation project. My interest is not in attempting to reproduce Xenakis’s compositional methods, but in exploring how relatively transparent probabilistic and statistical processes can become useful compositional tools: processes whose behavior can be understood, adjusted, combined, and ultimately shaped by the composer. In that respect, Lorrain’s article provides a particularly useful historical and conceptual point of departure. For anyone interested in going back to the original source, Denis Lorrain’s article can be found in the Computer Music Journal archive on JSTOR. I recommend reading it in full, particularly in the context of the kinds of generative and probabilistic compositional processes being discussed here: https://www.jstor.org/stable/3679442 One small correction I preserved from the earlier version: the title is “A Panoply of Stochastic ‘Canons’”—one n in canons, in the musical sense.

That way of thinking has remained with me ever since. It later found particularly fertile expression in programs such as CMask and nGen, both of which provided compositional front ends to Csound. What interested me about these systems was never randomness for its own sake. Rather, it was the possibility of constructing a field of constraints and tendencies: defining ranges, distributions, trajectories, masks, and probabilities, and then allowing the computer to articulate some of the many possible musical states contained within them. The composer designs a space of possibilities rather than prescribing every event that occupies it. Brian Eno’s discussions of generative systems in music intersect rather naturally with these ideas. Although Eno arrives at generative music from a somewhat different direction, I have long been attracted to his conception of making systems that can produce music rather than simply making a fixed sequence of musical events. There is an important shift of compositional perspective involved in this. One begins to think less exclusively about what happens next and more about what kinds of things are permitted to happen next, under what circumstances, and with what degree of likelihood. This connects, for me, with a much larger continuum between determinacy and indeterminacy that has occupied my thinking for many years. Both John Cage and Eno have been inspirational in this regard, despite the considerable differences between their musical worlds and their respective approaches to indeterminacy and generative process. What I take from them is not simply the idea of relinquishing control. The more interesting question concerns where control resides. A composer may surrender the precise determination of individual events while exercising considerable control over the environment, process, rules, or field of possibilities from which those events emerge. Joji Yuasa’s concept of control and de-control has also been central to my thinking about this relationship. I find the formulation particularly useful because it avoids treating determinacy and indeterminacy as opposites between which one must choose. Control and de-control can operate simultaneously, and they can operate at different structural levels of the same composition. One aspect of a musical process may be rigorously specified while another is deliberately permitted to fluctuate, wander, transform, or become unpredictable. The music consequently occupies a continuously adjustable gamut between determined and undetermined states rather than residing at either end of a simple binary opposition. My current Dynamic Event Generation project in Opusmodus returns quite deliberately to this territory. I am developing a collection of compositional tools in which larger musical intentions can be expressed as continuously changing conditions rather than solely as predetermined sequences of events. A pitch gamut might migrate through registral space; one tonal region might gradually become another; temporal density might accelerate or disperse; durations might expand or contract independently of the changing density of attacks. Individual events can be selected probabilistically while the larger behavior of the music remains very much the consequence of compositional decisions. This distinction is important to me. Stochastic composition need not mean simply asking a computer to make arbitrary choices. The interesting work occurs in designing the conditions surrounding those choices. Probability itself becomes something that can be composed, as can the boundaries within which probability operates. A process may therefore produce results that I did not specifically predict while still producing music that bears the imprint of decisions I made about its behavior. In this respect, I see Dynamic Event Generation as belonging to several intersecting lineages. There is the explicitly computational trajectory extending from Lorrain’s stochastic thinking through CMask and nGen, and now into the very different environment of Opusmodus. But there is also the broader aesthetic territory suggested to me by Cage, Eno, and Yuasa: the idea that composition can involve the creation of circumstances from which music emerges rather than the exhaustive specification of the music itself. Opusmodus provides a particularly interesting contemporary environment in which to revisit these questions because stochastic processes and algorithmic transformations can coexist with symbolic musical representation, notation, MIDI, and more conventional forms of musical organization. It therefore becomes possible to move rather freely between statistical thinking and traditional musical thinking, allowing a probabilistic process to encounter harmony, counterpoint, register, rhythm, instrumental writing, and other historically familiar aspects of composition. There is something particularly appealing to me about returning to these ideas after so many years of working with computer music. The machines, languages, and interfaces have changed considerably since Lorrain’s article appeared in 1980, but the underlying compositional question remains remarkably persistent: how much of a musical work must the composer specify, and how much can be entrusted to a carefully designed field of possibilities? Increasingly, I think the most interesting territory is not found at either extreme. It lies somewhere in the movement between them—in the continual negotiation of control and de-control, determinacy and indeterminacy, intention and emergence. Dynamic Event Generation is another attempt to explore that territory, not by relinquishing compositional agency, but by relocating it. The individual event becomes less important than the ecology in which events become possible, and composition becomes, at least in part, the art of designing that ecology.

Connecting an AI to Opusmodus through SwankSpeed, freedom of choice, and a closer connection between musical ideas and working code. Connecting an AI assistant to the running Lisp environment of Opusmodus opens up an interesting way of working. Through Swank, the assistant can propose code, evaluate expressions, examine results, and refine its suggestions within an ongoing session. For a composer working with algorithms, this creates a direct connection between musical intention, programming, and experimentation. An idea expressed in ordinary language can become a concrete procedure, tested against the musical material already present in Opusmodus. Two aspects make this approach particularly attractive: the speed of the interaction and the freedom to choose the AI used. What Does Swank Do?Swank is the Common Lisp server traditionally associated with SLIME, the interactive Lisp development environment for Emacs. It allows an external client to communicate with a running Lisp process. SLIME architecture. Opusmodus announced the return of SLIME/Swank support in version 4.0 and provides an extension file with setup instructions. This supplies the foundation for connecting external tools to its Lisp environment. Opusmodus setup announcement. An AI assistant can use this connection through a suitable client or bridge. The exchange follows a straightforward sequence: The assistant prepares a Lisp expression. The bridge sends it to Swank. Opusmodus evaluates the expression. The bridge returns the result to the assistant. The assistant uses that information to continue. The AI environment needs a way to communicate with Swank, either directly or through an external tool. Swank supplies access to the Lisp session; the bridge makes that access available to the assistant. Faster Execution and ExperimentationA considerable practical advantage is the speed with which this process can unfold. Sending an expression, receiving its result, and testing a revision can form a continuous sequence. Repeated copying, pasting, and manually reporting results can be reduced, allowing more experiments within the same working session. This is especially useful when developing a transformation or investigating an unexpected result. The assistant can test a small expression, examine what happened, adjust the code, and evaluate it again. Interactive evaluation is a fundamental capability of the SLIME/Swank environment. SLIME evaluation documentation. The main gain is a shorter cycle between an idea and a verified result. Swank does not inherently make a compositional algorithm compute faster: Opusmodus still evaluates the expression within its Lisp environment. Overall response time also depends on the AI model, the bridge, and the complexity of the calculation. Removing intermediate manual steps, however, can make experimentation considerably more fluid. Freedom to Choose the AIThe principle does not depend on one particular AI provider or model. Any AI system capable of using Swank—directly or through a compatible tool—can potentially participate in this workflow. That freedom allows the composer to choose an assistant according to several practical considerations: Its ability to write and explain Lisp. Its response speed. Its suitability for a particular task. Its cost and availability. The possibility of running it locally. The essential requirement is the ability to perform the relevant tool calls and interpret their results. A locally running model is also a possibility when its surrounding software supports the required connection. The assistant can change while the connection to Opusmodus continues to provide access to the same musical workspace. Working with the Actual Lisp SessionAn Opusmodus environment may contain personal functions, libraries developed over many years, and musical material stored in variables. Through focused queries, an assistant can work with those resources. It could check whether a function exists, inspect a sequence, or evaluate a short expression before incorporating it into a larger procedure. Even a simple calculation can provide useful feedback. For example, an assistant could verify the total duration of a rhythmic pattern expressed as fractions of a whole note: (let ((durations '(1/4 1/8 1/8 1/2))) (reduce #'+ durations))The result is: 1This small example illustrates the principle: the assistant can obtain an evaluated result from the session and use it to check an assumption. Documentation queries can also help establish which arguments a function expects. SLIME provides facilities for describing functions and symbols, looking up argument lists, and searching available symbols. A bridge can expose selected capabilities to the assistant. SLIME documentation facilities. From Musical Intention to a Working ExperimentConsider a request such as: With suitable tools, the assistant could inspect the sequence, propose a transformation, evaluate an initial version, and check the range of the resulting variations. The composer could then continue: The assistant can revise the procedure and test it against the same material. Each exchange becomes part of a developing experiment, with explicit rules and concrete results. The speed of this interaction encourages exploration. A composer can investigate several possibilities, compare their consequences, and refine the musical direction while the idea is still fresh. Learning and Developing Personal ToolsThis connection also offers a useful way to learn. A composer exploring Lisp can ask for an explanation, examine the evaluated result, and change one parameter at a time. The relationship between the expression and the musical data becomes easier to follow. More experienced users can apply the same process to: Developing personal functions. Investigating unexpected results. Clarifying the structure of existing code. Turning recurring experiments into reusable tools. Preserving the generated code and making the results readable gives the composer something concrete to inspect, modify, and reuse. Keeping the Composer in ControlSuccessful execution confirms that an expression ran. Its musical value remains a matter for the composer. The most useful workflow combines clear musical intentions, focused operations, and inspectable results. The assistant helps carry out and examine an experiment; the composer directs its development. Because Swank provides substantial access to the Lisp session, a local connection with trusted tools is a sensible starting point. The standard documentation describes localhost connections and SSH tunnelling for remote access. When using a remotely hosted AI, the bridge should also make clear which information is transmitted to it. Swank connection documentation. What interests me most is the combination of rapid experimentation and an open choice of assistant. The composer can choose an AI suited to the task, develop an idea through conversation, and test the resulting procedures in Opusmodus. The musical workspace becomes a place where intention, code, and results can inform one another continuously, with the composer directing the process.

Tintinnabuli Generative Model v1.4 — Four-State Tintinnabuli Cycle A generative model based on the tintinnabuli technique associated with Arvo Pärt, translating its characteristic relationship between a melodic M-voice and triad-derived T-voices into a systematic computational process. A modal M-voice is surrounded by upper and lower tintinnabuli voices whose pitches are determined relationally from an A-minor triadic field rather than through conventional harmonic progression. Across four successive regions, the model cycles through T+1/M/T−1, T+2/M/T−1, T+1/M/T−2, and T+2/M/T−2. The M-voice and rhythmic structure remain constant, while the changing T-voice positions progressively alter the registral and harmonic space surrounding the melody. In this way, Pärt's tintinnabuli principle becomes the starting point for a broader generative approach in which the M/T relationship itself functions as a formal parameter, allowing contrapuntal position and registral expansion to shape the larger musical form. This is a current research thread and a work in progress. My aspirations are to develop a more general compositional algorithm based on similar principles. More to come... Sound Example: Soundcloud Audio Arvo Part Inspirations.opmo

This program has been updated to v16.10. I have posted about it in the Forums.

Controlled Aleatorism v16.10 — Composer Form-Plan LibraryControlled Aleatorism v16.10 is an Opusmodus compositional system exploring the territory between fixed composition and controlled indeterminacy. Inspired in part by Witold Lutosławski’s concept of limited or controlled aleatorism, the project asks a contemporary algorithmic question: how much musical detail can remain mobile while the larger identity, behavior, and formal direction of a composition remain firmly in the hands of the composer? The program is organized around a registrally articulated twelve-note pitch field shared by flute, violoncello, and harp. Rather than treating this material as a conventional twelve-tone row, the algorithm regards it as a persistent harmonic environment through which the instruments move with different degrees of mobility. Four behavioral states—Suspended, Lyrical, Contrapuntal, and Agitated—establish distinct musical grammars governing rhythm, gesture, silence, instrumental roles, pitch movement, motivic memory, and inter-instrumental exchange. The pitch world remains consistent while the manner of inhabiting it changes. An important aspect of the model is memory. Rhythmic motives can persist and mutate within individual lines, migrate among instruments, and leave transformed traces across formal regions. The instruments therefore do not merely generate independent stochastic events; their behavior reflects something of what has already occurred. Randomness becomes controlled mobility, in which present conditions influence subsequent possibilities. Version 16.10 introduces the Composer Form-Plan Library, bringing large-scale morphology explicitly under composer control. Preset trajectories can move from openness toward density and back again, alternate static and active regions, accumulate toward a climax, or emphasize broad or highly agitated behavior. A custom mode allows the composer to specify the precise succession and relative duration of behavioral states. The guiding hierarchy is deliberately straightforward: the composer determines the form; the form selects the behavioral state; the state determines the musical grammar; and controlled aleatory animates the interior of that grammar. Sound Example: Soundcloud Audio Contolled Aleatorism v16.10 — Compositional Synopsis.pdf Contolled Aleatorism v16.10 — Easy Start-up Guide.pdf Opusmodus source code and comprehensive manual at the link below:

This short essay about Joji Yuasa's methods of composing, and in particular his viewpoints on pitch material and pitch control, may be of interest to some of the Opusmodus community. This is on Substack at the link below:

I am sure this will be a great journey for many OM users.

The fully realized program and documentation will be forthcoming at Substack in a short time.

I am beginning this blog as a place to share observations from my ongoing work with Opusmodus: not so much finished articles or formal presentations, but glimpses into the process of developing new compositional ideas, programming techniques, and musical systems. This blog will not take the place of my more detailed writing at Substack, where I publish longer essays, extended discussions of compositional method, complete Opusmodus projects, documentation, and other materials intended for more sustained study. I think of that work as a more developed view from inside the composer's workshop, where an idea can be followed from its conceptual beginnings through programming, experimentation, revision, and eventually into music. Here at the Opusmodus site, I would like to do something somewhat different. This can be a notebook of sorts: a place for developmental observations, discoveries, questions, experiments, and occasional fragments of code that arise while I am actually working. Some ideas may eventually become larger projects; others may remain small experiments that nevertheless reveal something useful about composing with Opusmodus. Much of my recent work has involved trying to move beyond the idea of algorithmic composition as simply a means of generating musical material. I am increasingly interested in constructing systems that embody aspects of compositional behavior: counterpoint, harmonic direction, instrumental interaction, density, silence, phrase formation, memory, variation, and large-scale tendencies that unfold through time. Opusmodus is particularly interesting to me because it permits these musical concerns to exist very close to the programming itself. The code can become not merely a mechanism for producing notes, but a way of articulating a compositional idea. I am also interested in the developmental process itself. A program rarely arrives fully formed. One version suggests another. A technically successful solution may produce an uninteresting musical result, while an apparent programming limitation may unexpectedly suggest a new compositional direction. Listening therefore remains central to the process. I generate material, listen, revise the underlying assumptions, alter the program, and listen again. In this respect, programming becomes part of composition rather than a preliminary technical activity. From time to time I will use this blog to document those moments: what I am trying to accomplish, what seems to be working, what is not working, and what a particular experiment suggests as the next step. I may also discuss broader questions about generative composition, computer-assisted composition, Lisp, musical representation, and the relationship between algorithmic procedures and musical intuition. I hope this will make the blog useful both to experienced Opusmodus users and to those who are still finding their way into the environment. One of the fascinating things about Opusmodus is that there is rarely only one way to approach a musical problem. Seeing how another composer formulates a problem can sometimes be as useful as seeing the eventual solution. So this will be a record of work in motion rather than a catalogue of finished results. Some entries may lead eventually to complete compositions or substantial Opusmodus applications; others may simply document an interesting turn in the road. In either case, the emphasis will remain on the intersection that continues to fascinate me: where musical imagination, listening, formal thought, and programming begin to act upon one another. That seems an appropriate place for a composer's notebook to begin. You can find my Substack here: THE LISTENING COMPOSER | Robert Scott Thompson | SubstackFrom inside the composer’s workshop: explorations of composition, listening, electronic and computer music, creative technology, musical history, and a life spent making sound. Click to read THE LISTE

This example is from Controlled Aleatorism v15.11.1 - a deeper stage of deveopment of this compositional algorithm using Opusmodus. Sound Example: Soundcloud Audio Sound Example 2: Soundcloud Audio It is a work in progress - here is part of the composer controls in the code as I am developing it. ;; Controlled Aleatorism v15.12 — Formal Morphology ;; after the Controlled Aleatory Experiment after Lutoslawski ;; ;; DEVELOPMENT FROM v15.1: ;; The successful field-memory and instrumental-character architecture ;; remains intact. v15.2 adds a shared latent trajectory that can exert ;; occasional attraction or avoidance upon each instrumental path. ;; ;; Attraction maps the same shared trajectory onto each instrument's ;; registral version of the twelve-tone field. Avoidance maps that same ;; trajectory onto a six-position rotation of the field. Most events remain ;; independently generated, so interaction colors rather than replaces ;; autonomous behavior. ;; ;; PRINCIPLE: ;; FIELD -> MEMORY -> INDEPENDENT PATH -> SHARED ATTRACTOR/REPELLER ;; -> INSTRUMENTAL PATH -> RHYTHMIC REALIZATION ;; ;; No user-defined Lisp functions are introduced. ;; Automatic MIDI export remains active. ;; ============================================================ ;; COMPOSER CONTROL PANEL ;; ============================================================ ;; ;; v15.5 begins the transition from a fixed generative composition toward ;; a composer-directed compositional instrument. The successful v15.4.6 ;; common-active-span closure remains unchanged. ;; ;; The first control layer exposes five musically meaningful variables: ;; ;; ACTIVITY probability that an otherwise sounding rhythmic event ;; remains active after the existing formal density map. ;; ;; MOBILITY probability of using the more mobile independent path ;; rather than the shared attraction/avoidance behavior. ;; ;; FIELD WINDOW number of ordered positions from the twelve-tone field ;; available to the shared interaction layer. ;; ;; COHESION probability that a non-independent event is attracted ;; toward the shared trajectory. Remaining interaction ;; events use the avoidance path. ;; ;; REGISTER SPREAD 0 = retain original register ;; 1 = permit the full octave-displacement trajectory. ;; ;; Values between 0.0 and 1.0 are recommended unless otherwise noted. (setf *master-seed* 6887) ;; ============================================================ ;; GLOBAL DURATION ;; ============================================================ ;; ;; Requested approximate duration in minutes. The program generates enough ;; rhythmic material to exceed this horizon, then trims all three parts to ;; the requested musical span while retaining the sounding-span collective ;; closure logic. ;; ;; At tempo 118, 8 minutes = 944 quarter-note beats = 236 whole-note units. (setf *output-duration-minutes* 1.0) (setf *tempo* 118) ;; Small generation reserve so late activity/breathing rests do not normally ;; leave the generated material shorter than the requested horizon. (setf *duration-generation-reserve* 1.15) (setf target-score-span (/ (* *output-duration-minutes* *tempo*) 4.0)) ;; ============================================================ ;; FORMAL MORPHOLOGY ;; ============================================================ ;; Emergence -> Expansion -> Intensification -> Dissolution ;; Proportions should total 1.0. (setf *formal-proportions* '(0.20 0.30 0.25 0.25)) ;; Global density targets for the four regions. (setf *formal-density* '(0.42 0.72 0.94 0.38)) ;; Per-instrument activity targets. (setf *formal-fl-activity* '(0.48 0.78 0.96 0.36)) (setf *formal-vc-activity* '(0.56 0.76 0.92 0.42)) (setf *formal-hp-activity* '(0.40 0.72 0.90 0.30)) ;; 0.0 = existing systems dominate; 1.0 = morphology dominates. (setf *formal-morphology-influence* 0.80) ;; GLOBAL EVENT DENSITY ;; ;; Master probability applied to otherwise sounding events across the entire ;; trio. 1.0 preserves all events admitted by the existing activity, ;; density, and breath systems. Lower values progressively thin the whole ;; ensemble without changing pitch navigation, rhythmic proportions, or ;; phrase-breath logic. ;; ;; Useful starting points: ;; 1.00 = no additional thinning ;; 0.85 = light thinning ;; 0.70 = moderate thinning ;; 0.50 = sparse ;; ;; This is deliberately a single global control so that the complete texture ;; can be made more or less event-dense while preserving the relative ;; instrumental behavior already established in v15.7.1. (setf *global-event-density* 1.0) (setf *fl-activity* 0.88) (setf *vc-activity* 0.88) (setf *hp-activity* 0.88) (setf *fl-mobility* 0.77) (setf *vc-mobility* 0.78) (setf *hp-mobility* 0.74) (setf *field-window* 12) (setf *ensemble-cohesion* 0.60) ;; BEHAVIORAL TRAJECTORIES ;; Eight values describe eight successive formal regions. ;; Values should normally remain between 0.0 and 1.0. ;; ;; Activity trajectories scale the existing per-instrument activity controls. ;; Mobility trajectories determine the changing preference for independent ;; field navigation. Cohesion controls attraction within the interacting ;; portion of the texture. (setf *fl-activity-trajectory* '(0.45 0.60 0.78 1.00 0.92 0.75 0.55 0.35)) (setf *vc-activity-trajectory* '(0.55 0.68 0.82 0.95 1.00 0.82 0.62 0.42)) (setf *hp-activity-trajectory* '(0.38 0.55 0.75 0.92 0.88 0.70 0.48 0.30)) ;; PHRASE / BREATH CONTROLS ;; ;; v15.7.1 measures a breath in MUSICAL TIME rather than event count. ;; The values below are expressed in whole-note units: ;; ;; 1/4 = quarter note ;; 1/2 = half note ;; 1 = whole note / one 4/4 measure ;; 2 = two 4/4 measures ;; ;; A breath begins probabilistically, then continues only until the selected ;; temporal target has been reached. The current event is never split, so ;; the realized breath may exceed the target by the duration of one event. ;; ;; Set a probability to 0.0 to disable breathing for that instrument. etc.

I noticed this too. :within with pitches seem broken. Jesper

Could anybody explain why this is not working. (Was working before ...) (setf voc4 '((h g2 pp q q) (h g2 pp q q) (h d2 pp q q) (h g2 pp q q) (h g2 pp q q) (h g2 pp q d2g2 d2g2) (h d2 pp d2) (h g2 pp -) (h g2 pp q q) (h g2 pp q q) (h d2 pp q q) (h g2 pp q q) (h g2 pp q q) (h g2 pp q d2g2 d2g2) (h d2 pp d2) (h g2 pp -) (h eb2 pp q q) (h bb1 pp bb1) (h c2 pp q q) (h d2 pp d2) (h eb2 pp q d2 c2) (h bb1 pp e1) (h f1 pp q q) (h bb1 pp -) (h eb2 pp q bb1 g1) (h bb1 pp q q eb2) (h f2 pp q eb2 bb1) (h eb2 pp q q d2) (h cs2 pp q d2 d2) (h e2 pp q d2 cs2) (h d2 pp d2) (h g1 pp -))) (setf voc4 (dictum '(:within (e1 a1) :do (pitch-transpose 12 x)) voc4)) Thanks a lot for a hint, Achim

Returning to Controlled AleatorismI have recently returned to an Opusmodus algorithm that I developed some time ago around the idea of controlled aleatorism. Coming back to it has reminded me how persistent my affinity for the music and thinking of Witold Lutosławski has been. His approach to limited or controlled aleatorism has always interested me precisely because it does not represent an abandonment of compositional responsibility. Rather, it establishes carefully defined fields within which individual musical events may acquire a degree of independence, unpredictability, and life. My engagement with Lutosławski goes back much further than my work with Opusmodus. It was my mentor, Joji Yuasa, who encouraged me to study Lutosławski's music carefully. Joji regarded him as perhaps one of the most important figures in post-serial music during the latter half of the twentieth century, and his enthusiasm encouraged me to listen beyond the immediately recognizable surface of the music—to consider how freedom and control, harmonic organization and indeterminacy, could coexist within a rigorously conceived compositional structure. That question remains very much alive for me. Returning to this algorithm is therefore not simply a matter of revisiting old code. I am reconsidering the musical assumptions behind it, particularly the relationship between aleatoric mobility and what I think of as a registrally articulated twelve-tone pitch-class field. Rather than treating the twelve tones primarily as serial material to be permuted, I am interested in establishing an intervallic geography and allowing independent instrumental voices to find different pathways through it. The algorithm is very much a work in progress, and I expect to share more extensive documentation, discussion of the compositional thinking behind it, and the evolving Opusmodus source code through my Substack, The Listening Composer. As the project develops, I want to make the code useful not only as a finished compositional tool but also as a way of examining how musical ideas can be articulated algorithmically and then subjected to further experimentation. In the meantime, however, I am happy to share this early-stage version of the algorithm with anyone who would like to work with it. There is something particularly appropriate about allowing a project concerned with controlled indeterminacy to enter the hands of other composers before all of its possibilities have been settled. Those who are interested can explore it, alter its parameters, substitute their own pitch fields, and perhaps discover possibilities in it that I have not yet encountered myself. In that sense, returning to this algorithm is also another way of returning to questions that Lutosławski, Yuasa, and others opened for me many years ago. The technology changes, but the deeper compositional problem remains wonderfully persistent: how much can we determine, how much can we release, and what kind of music emerges in the space between the two? This is what the output music looks like with the current parameter settings: Controlled-Aleatorism-15.0-Field-Navigation.opmo Controlled Aleatorism v15.1 — Field Memory and Instrumental CharacterVersion 15.1 extends the field-navigation principles established in v15.0 by introducing memory and differentiated instrumental behavior. The underlying registrally articulated twelve-tone pitch-class field remains unchanged, but the flute, cello, and harp now follow independent Brownian trajectories through differently organized versions of that field. Because Brownian motion retains a relationship between successive values, each new position is influenced by what has immediately preceded it, creating continuity without predetermined melodic lines. A significant change is that pitch navigation now unfolds continuously across the complete formal span rather than being generated as a short cell and then literally repeated. The recurring rhythmic structures still provide coherence, while the evolving pitch paths allow the three instruments to develop distinct behavioral identities. The result moves the algorithm closer to its central compositional objective: a carefully defined musical environment within which controlled freedom, memory, and instrumental independence can coexist. From this refinement one can get a sense of the direction my research on this process is headed. More to come... Controlled-Aleatorism-15.1-Field-Memory-and-Instrumental-Character.opmo

Comments in an Opusmodus program can do much more than explain code. Used thoughtfully, they preserve compositional intention, clarify musical structure, identify important parameters, and document the evolution of a generative process. This article introduces the Common Lisp comment syntax used by Opusmodus and considers how effective commenting can transform a program into an executable compositional notebook—one that remains understandable, adaptable, and musically useful long after it was first written. You can read this short article here.

Opusmodus introduces two new horizontal notation layouts on Mac and Windows, alongside the familiar Vertical layout. Continuous Scrolling moves the score smoothly beneath a fixed central playhead, while Horizontal Page Turn keeps the notation stationary and advances to the next section as playback reaches the window’s edge. A fixed left-hand panel displays instrument abbreviations, clefs, key and time signatures, and the tempo applicable to the visible score. Best wishes, Janusz

Thank you, Robert.

Here is a screenshot output from the preprocessor algorithm. The original is below. The music is Fantasy, by John Dowland. It should be noted that the creation of the multi-voice strands is neither perfect nor ideal - and is perhaps not even musically sensible! The purpose of the algorithm is to merely to deconstruct and atomize a polyphonic MIDI file to use the independent voice materials in various ways compositionally. One can imagine a number of frameworks to exploit this type of material in compositional contexts. Needless to say, this is difficult work to do well. The notion of building an intelligent application that understands the nuance of counterpoint is perhaps impossible. It is definitely beyond my scope. However, this kind of tool does provide some interesting possibilities as a creator of INPUT for the Burroughs Cut-up Engine 4.5. And that is the main goal for me in creating it. I am trying to refine this approach in a more musically sensitive direction but it is daunting and in the end may not really be all that possible, at least for me. The current version of this algorithm provides the means for durational augmentation and also for basic quantization of the output durations. Both helpful attributes for this process in context. Program Output: Please note that this particular output example includes note duration augmentation and quantization. Often the output of the MIDI preprocessor does not produce "good looking" notation. This is not really all that important to the compositional process of the Burroughs Cut-up Engine v4.5. The use of the output of this program is as MIDI information and not specifically for notation. Of course, the output of Burroughs v4.5 could be as notation as well for import to a score editing program such as Sibelius. Original MIDI File: Here is one approach to sonifying the multi-strand output. This is the result of running the Burroughs Cut-up Engine v4.5 on the multi-strand output and using the same ensemble.

Yes, the Opusmodus program code (.opmo file) is at the link provided to Substack. I will try to add a before/after graphic in musical notation soon. It would be interesting to learn more about how you approached this particular problem. It is not all that "easy."

Incredible, I was writing the same thing;-)

I think including a score example (.opmo file) would make it easier to understand what you’re trying to communicate while examining the process.

The Burroughs Polyphonic MIDI Preprocessor v1.2.8 is an Opusmodus utility designed to transform a polyphonic MIDI source into a collection of independent monophonic musical voices while preserving the pitch content and overall temporal structure of the original material. Its principal application is preparation of polyphonic source material for the Burroughs Cut-Up Engine v4.5.1 and later compatible versions. The Burroughs engine works most effectively when contrapuntal material is represented as separate MIDI components rather than as a single polyphonic stream. The Preprocessor performs that separation automatically. The program is not a conventional MIDI channel splitter. It analyzes the musical content of a polyphonic source and attempts to infer continuing contrapuntal voices according to pitch proximity, melodic history, repeated tones, registral behavior, and periods of inactivity. The fundamental design principle is: The program may decide which voice receives a source pitch, but it must not decide what that pitch should be. Consequently, v1.2.8 does not intentionally transpose, harmonize, substitute, or invent sounding pitches during voice allocation. Opusmodus Souce Code and the new Burroughs Cut-Up Engine v4.5.1 are found at this link: Burroughs Polyphonic MIDI Preprocessor v1.2.8 - Compositional Synopsis.pdf Burroughs Polyphonic MIDI Preprocessor v1.2.8 - Getting Started Guide.pdf Burroughs Polyphonic MIDI Preprocessor v1.2.8 - Use Manual.pdf

Dear Robert, Congratulations for the reflections. I think it´s very important to elaborate our compositional process as text, to really describe step by step the intentions we have with our code: the apparent and hidden algorithms, the functions we specially create for specific music tasks and also thoughts about esthetic orientation and how to achieve our goals. Sometimes just putting comments on the code is not enough. As humans, we need things to go slower and with intention. Also the newer generations need to differentiate AI process from LISP programming. Much people simply think that using Opusmodus (or other CAC softwares) is a kind of cheating, that one must compose only manually. Thanks a lot for the text. Best, Julio

Yes, Opusmodus forces you to think. Without complexity, as in humanity, we would be lost.