#algorithmic composition

[processzine-org]

Between Lines — IMAGE→SRT (photos that sing)

I’ve added another new sister-tool to Between Lines: Image → SRT. Upload a still image, and it writes a subtitle file whose timings and “words” are derived from the picture. Feed that SRT into Between Lines and you get a playable score.

Below: a short render of Beksiński’s 1973 “Night Creeper” using my “Ritual Dread” settings, plus the, SRT output, mosaic preview and the app screenshot.

Visit Original Link

How it works (quick)

Grid the image into rows × columns (like a page: left→right, top→bottom).

Average each cell to a single shade/colour.

Map that value → a note:

grayscale: darker = lower pitch / longer sustain; light = higher; pure white can be treated as silence (invert for the opposite).

colour (hue) mode: hue picks pitch region, brightness can gate silence.

Timing: each cell = a fixed duration (e.g., 0.12 s). Optional row gap adds breath between lines—very phrase-like.

The tool writes two things:

an .srt file (the “score”), and

a mosaic preview PNG showing the exact grid the music came from (optionally with grid lines / silent cells marked).

Then open the SRT in /Between Lines/ and choose scale, stereo width, chord pad, reverb, etc., to match the image’s mood.

Pipeline: Image → SRT → /Between Lines/ → WAV (+ Mosaic)

Why SRT again?

SRT is the project’s “limbo layer.” Everything—speech, music, images—passes through it. Timing + minimal text become a neutral score that can be re-interpreted: seen (spectrograms), heard (sonification), or re-written. It’s the gap where meaning suspends… and forms.

Case study — Night Creeper

I ran the painting through Image→SRT (70×40 grid, 0.12 s/cell, hue with white→silence) and sonified it with a slow, heavy preset:

Scale: phrygian

Note band: 90–520 Hz

Articulation: 0.95 (legato)

Sustain (×): 2.8

Stereo width: 0.75

Caption chord pad: 0.08

Floor (drone): 0.05 @ 50–85 Hz

Reverb: 0.22 • Saturation: 1.03

Result: a crawling, heat-haze drone that fits the sodium-orange, rusted dread of the piece.

Knobs that matter

Rows / Columns — resolution of the “reading.”

Seconds per cell + Row gap — pace and phrasing.

Silence threshold (+ invert) — which parts of the image become rests.

Mapping — grayscale or hue.

Word-length range — acts like sustain inside /Between Lines/.

In /Between Lines/ — scale (chromatic, phrygian, aeolian, dorian, lydian…), stereo width, caption-chord pad, smoothing, reverb, saturation.

Where this is heading

All the tools are converging into a single space: Between Lines Studio — a desktop (or web) app where SRT is the spine, and you can go:

Audio → SRT (beats/bars/onsets)

Image → SRT (grid reading)

Text → SRT (write your own score)

then SRT → Music / Spectrogram / Image mosaic, and (for me) onward into signal // noise.

Upload a photo. Get a composition.

[michaelgogins]

What is musical composition vs. live coding?

Working with Tidal Cycles and integrating its JavaScript offspring, Strudel, with Csound, has been very interesting and invigorating. You can see some of what I have been doing here.

Just recently, I noticed that Victor Lazzarini has created an online live coding environment for Csound taking off from the p5.js editor, although he has not (yet?) published the code.

As an algorithmic composer, I have long considered that the code of an algorithmic composition is the score of the composition. And it would follow that live coding, which involves writing code during the performance, would be something like improvisation.

But live coding is still code! So, in a sense, it is also composition.

So, what's the difference between a composition that results in a fixed medium, and a composition that is partly improvised?

The root meaning of "compose" is "put together." Musical composition is the art of putting together elements of music to create a new work.

The difference between algorithmic composition and live coding, as I see it, is that "composition" results in a new work that has a relatively fixed form such that one can hear it all over again and will, because one wants to hear the piece all over again.

Lines are blurred because of course, live coding sessions, or any other improvisations, can be recorded. And then there is a fixed medium that can be heard all over again.

But I think the distinction has been clarified. Composition intends to create a fixed work that is worth hearing again.

The fact that this is possible at all, and highly valued in many cultures, is telling us something important, something about a ritual of attention.

[michaelgogins]

Composing in Lisp

I have recently completed several algorithmic composition projects involving Common Lisp. These include:

Bringing Drew Krause’s code into my csound-extended repository as the nudruz system, and making it usable for other people besides Drew by creating a nudruz.asd system definition. Drew’s talk is well worth a look, it is what inspired me to do this stuff.

Implementing a foreign function interface for Csound in OpenMusic.

Embedding the ability to run Lisp code, including both the Lisp version of Common Music and Drew’s code, in my CsoundAC algorithmic composition system, written in C++. This is based on Embeddable Common Lisp.

There are things that I do not, or at least did not, like about Lisp. And there are things that I do like. But, now that I have moved on from just getting Lisp example pieces to work, to actually composing my own pieces in Lisp, I am finally beginning to “get” Lisp.

Things that I do not, or did not, like:

Many incompatible or partial implementations of the ANSI Lisp standard, resulting in many libraries that worked with only one or a few implementations of Lisp. Thanks to the general adoption of Another System Definition Facility (ASDF), this finally seems to have changed. After I created an ASDF system for nudruz using Steel Bank Common Lisp, it loaded and ran in Embeddable Common Lisp with only one minor change (getting rid of clocc.fasl; thanks, azimut).

Lisp syntax is primitive, arcane, and full of subtle “gotchas.” This has not changed. And I still do not like it.

Things that I do like:

Common Lisp has both an interpreter so it can act as a scripting language, and a machine language compiler that produces programs running almost as fast as compiled C or C++ code.

Thanks to ASDF, the ASDF system definition can act as a build system for compiling that system. 

Although Lisp syntax is primitive and arcane, it is closely based upon the lambda calculus, which is one of several interchangeable formal representations of the universal Turing machine.

What I have found is that the fairy tales of the Lisp hackers seem, so far, to have some truth. It will take several months, at least, for me to get a more complete feeling for the usefulness of Common Lisp as compared to my current main languages, C++ and JavaScript. But, so far, I am finding that Lisp is more powerful, and I can program faster in Lisp.

Why is this? I think it is because:

The Common Lisp runtime is both an interpreter and a compiler, so I can program without having to compile any code. This really speeds up programming. Once I have an ASDF definition, I don’t need a build system unless I am using native code. I still end up with compiled code.

Although Lisp syntax is primitive and arcane, the fact that it is directly based on the lambda calculus means that it is never necessary to dig down to a deeper level of logic, and a new layer of abstraction can be introduced at any time, at any level of abstraction. This usually cuts down the amount of code that one must write!

[music01302053497]

{

"@context": "https://schema.org",

"@type": "Article",

"headline": "",

"description": "",

"articleSection": "music",

"keywords": "\"The Rise of AI-Generated Music: How Technology is Shaping the Future of Songwriting and Production\"",

"datePublished": "2026-02-04T11:37:05.811168",

"dateModified": "2026-02-04T11:37:05.811184"

}

[michaelgogins]

A Very Brief Glimpse of the Literature

I just took a peek at recent literature in the field of algorithmic music composition. Almost all work now is concerned with applications of artificial intelligence.

In my own work as an algorithmic composer and author of music software, I use AI in the form of ChatGPT every day. I use it to prototype code, to summarize literature, and to critique my own concepts and algorithms. And I will keep using it, because it speeds up my work.

Nevertheless, I have nearly zero interest in actually using AI to compose.

That is because I feel, based on both understanding and experience, that AI is not capable of the level of musical originality to which I aspire.

Much of the literature on AI composition that I see is about:

Composing music for use without having to pay a composer, e.g. for games, ads, and so on.

Musicological research, often with commercial applications.

I have no interest in either of these things. I am simply trying to use algorithms to compose the kind of music that I would like to hear, but that does not yet exist. Again, I don’t think AI is up to this (yet?). That leaves me with the following approaches:

Using the phenomenon of computational irreducibility as exemplified in fractals, chaotic attractors of dynamical systems, and so on. This in turn can be done:

By manually tweaking the algorithm to produce music that gets closer and closer to what I want to hear. Most of my music that I actually like has been done this way.

By interactively exploring a map of the parameter space for such algorithms — parametric composition. So far this is mostly a concept, because it is computationally very expensive.

Using a custom language with a recursive structure and terse vocabulary, so far just Lindenmayer systems, as this permits me to effect with simple edits changes throughout a piece and on all scales at once.

TL;DR: AI composition tries to use algorithms to make something that sounds like existing music; I am trying to use algorithms to make music that sounds new.

[tekesuke1986]

206

SuperColliderで音をポーポー出せるようにした　音響はパラメータ渡せるようにするつもり

こういう簡単なやつよりそろそろ本質的なところ、複数トラック生成アルゴリズムがんばらんと

[michaelgogins]

The Tide of AI

I’ve been working with generative artificial intelligence (AI here) now for several years, trying to understand a bit about how it works, and following discussions by those much more knowledgeable and more concerned about it than I.

My main uses of AI have been to jumpstart my solutions to programming problems, and to answer questions about many different things in a better way than mere search engines. I also use image generating AIs to produce illustrations for some of my favorite science fiction novels.

I have come to some tentative conclusions.

AI is not now conscious in any sense.

AI is not now capable of telling the difference between its training data and the external world.

AI can produce very useful and rapid solutions for me based on solutions that other people have found.

If a solution has not already been found, then AI has some ability to reason its way to a solution.

Such solutions are not always correct. I run into many outright mistakes. Such mistakes can only be fixed by a human expert, but they sometimes still are quite useful as hints towards a correct solution.

AI is improving rapidly.

The better AI gets, the more the human workflow will involve it. And in looking at how others are using AI, particularly in visual art, I can see that future work in many if not most fields of art, science, engineering, and other forms of expertise will involve a continuous dialogue with AI.

And yet, the AI is doing so much work for one behind the scenes, it’s all but impossible to control everything about the solution. For example, in generating illustrations for Jack Vance’s Demon Princes novels, certain idealized images of the characters are created. If Drusilla Wayles is shown, to make her blond not brunette and full-figured not slim, and dressed in any detailed style, requires a fair amount of work in writing more detailed prompts.

I see this as an obstacle to real originality. In other words, the easier it becomes to use AI and the better the solutions are, the more tempting it will become for me, and probably many other people, to use the AI solution. I feel this will interpose a lot of extra work before getting to real originality without, perhaps, the author fully realizing that. And I feel this could lead of sighs of resignation.

That may well make it harder to achieve true originality in many fields.

I plan to try using AI to compose musical scores as MIDI files, and to design new Csound instruments. That will be probably more enlightening for me than fooling around with illustrating some of my favorite stories, although I will keep doing that.

One thing I am looking for is help with pieces I’m working on. Let’s suppose I have code that produces a complete piece of music, but there are problems I don’t see how to fix. I’d like to be able to say something like “the B section is too much like the A and C sections, edit this code to make the B section not such an obvious rehash of the parts of the A and C sections,” and get some code that either does that, or provides a hint for how I can do that.

I will report on my experiences here.

[michaelgogins]

Algorithmic Composition in Reaper

As a result of working with Menno to get CsoundAC working as ReaScript in Reaper, I have come to appreciate some of the pros and cons of doing algorithmic composition in Reaper projects.

I will have more to say about this in the near future….

In the meantime, here is my first take on the pros and cons.

Cons first:

This can be done only on desktop platforms (for now). All my experience to date is with macOS.

This can be done only in 12-tone equal temperament (for now).

ReaScript actions are not stored in project files, but are externally stored.

Pros:

It works very well.

As long as the algorithmic composition library is written in Python or has a Python interface, everything can be used.

Complex scores can be generated quickly.

Scores can be generated to use either CsoundVST3, or any other synthesizer plugin in Reaper, or a mixture.

By setting up start times in Reaper, or loops, it is possible to test changes in a score generating script very quickly without have to listen to things all that way through. This is a huge advantage.

It is possible to use CsoundAC in conjunction with other algorithmic composition systems that work in Python. This is potentially a huge advantage.