Blind Search and Flexible Product Visions
Source: Oliver Bown, “Blind Search and Flexible Product Visions: The Sociotechnical Shaping of Generative Music Engines,” AI & Society 40 (2025), 585–603. Full article
Claim
Commercial generative music comes from a whole production system. Product aims, musical assets, rendering software, company workflows, infrastructure, investors, interfaces and user habits shape one another until a provisional design may become a lasting condition of musical culture.
Evidence and method
Bown compares four firms through interviews with founders and developers, public and archival material, user forums and participant observation at one company. He did not interview Endel and had limited access to each firm’s technical details, so parts of his system analysis remain informed inference (pp. 585–586, 602–603).
He defines a generative music engine as real-time rendering software, musical assets, backend software and the organisational practices that deliver changing music. The engine may use AI, although simple rules can arrange stems and loops without machine learning (pp. 587–588).
The central production problem is the automated arrangement and mixing of musical elements. A platform must decide how much one system governs, whether artists can define their own rules, how its tools connect to existing DAWs and which real-time effects a phone can run (p. 588).
In Bown’s Endel analysis, listeners choose broad scenarios such as focus or sleep instead of selecting artists. The company keeps artist collaborations inside its branded interface and presents adaptive, bioresponsive sound as a service, although the audible and functional value of that adaptation remains hard to establish (pp. 592–593).
Bown’s close listening describes loop-like material that changes slowly enough to avoid irritation. He argues that Endel’s one-button interface and removal of the artist “shopfront” may matter more to the product than fine-grained generative novelty (pp. 592–593, 599).
The in-house process joins producers and sound assets to a proprietary engine, so the company can subsume an artist collaboration under the product rather than deliver a normal artist release. The engine, tagged assets, team, user base, data and intellectual property also retain value if the original product changes or another firm buys it (pp. 599–602).
Concepts
- Generative music engine: The technical and organisational system that produces dynamic music, including more than its generative algorithm.
- Sociotechnical shaping: Technical, musical, economic and cultural choices constrain one another.
- Flexible product vision: A strong public promise guides investment while the firm keeps searching for a viable use.
- Residual value: Code, datasets, assets, users, patents and teams can retain value apart from the stated music product.
- Artist shopfront and platform closure: Endel reduces the familiar interface of named artists and releases, while early commercial choices can become fixed conditions for later music.
Limits
Bown provides the strongest direct academic account of the commercial space, but he does not document Endel’s source code, internal composition tools or artist contracts. His description of the sound comes from close listening and architectural inference rather than a confirmed account of the engine. He also calls the Endel focus paper arm’s-length and paraphrases its outcome as task completion, although the company-funded paper involved Endel in study design and measured a proprietary EEG-derived focus score instead of work output.
Presentation use
Use Bown as the presentation’s main case study. Start with his broad engine model, then locate Endel’s assets, rules, runtime, inputs, interface, organisation and business inside it. The case can then stay on changing musicianship without becoming a technical report.
Frame the new musicianship as designing material and possible behaviour inside a proprietary system. Musicians create timbres, stems, transition-safe elements, limits and rules within a runtime controlled by the company, while users choose a coarse function. Keep detailed patent architecture on a backup slide unless one mechanism directly supports the claim.