This article was written in 2024-25, while I was working in the Logos Foundation. The article describes the challenges of the (software) control of the robot orchestra in Logos. It also gives specific information about how this control is connected to the artistic practices, repertoire and history of Logos. The text was based on my own experience and knowledge (of people and sources in Logos), and on consultation with Kristof Lauwers and Godfried-Willem Raes.
I didn't rewrite the text (yet), a few additions were made after January, 2025 and these are indicated.
-- -- --
Controlling the Logos music robots
This article aims to answer the following questions: 1. What are the implications of the current control system (MIDI) for the Logos music robots? 2. How is GMT (Logos software) integrated with the robots and their repertoire? 3. How can we make the control system more open and accessible?
All Logos music robots are controlled via MIDI commands, meaning control is carried out in accordance with the standard and widely used MIDI protocol. As a result, the robots are, in principle, widely accessible for use, performance and testing. Over the past 35 years, this has indeed been done extensively by (external) musicians, instrument makers and researchers.
Unlike synthesisers or samplers, there is little or no standardisation in the construction, let alone the musical practice, of music robots. After all, this is a young and new field of research that is still in full development. Internationally, there is little or no consensus on, for example, the components a trumpet robot must have, or on its internal workings or control systems, etc. The development of musical robots at Logos since 1989, primarily by G.-W. Raes, was and remains a (historical) work in progress, in which instruments were built according to the best available insights at a given moment and, a few years later - following intensive use of the instruments - were adapted in line with newly acquired insights.
The decision to consistently use the MIDI protocol has brought, and continues to bring, benefits, mainly because it guarantees openness and accessibility. However, as the robot orchestra has grown to more than 85 robots and there is no 'standard robot version' of the MIDI protocol, the MIDI implementation for the Logos robots can only be homogeneous to a limited extent, and it requires a great deal of work and preparation to make music with such a large group of musical robots.
The limitations of MIDI in terms of speed and bandwidth have not presented any significant drawbacks for the Logos music robots. As these robots are physical musical instruments with mechanical parts, there are 'inherent' physical limitations, such as the speed at which a flute's key opens and closes or a percussion stick strikes a drumhead up and down. So the 'slowness' of MIDI has not proved to be a major problem. (To clarify: it is the 'external' control of the music robots - via the musician and user - that takes place according to the MIDI protocol. All the music robots themselves have built-in hardware microcontrollers - a kind of mini-computers - which enable the movement and control of the instrument's components, for example via electromagnets. This hardware control has, of course, benefited from technological developments over the past decades and the associated increases in speed and complexity.)
The Logos music robots have therefore been tested and successfully used by more than a hundred performers, composers and instrument makers over the past 35 years. Nevertheless, this usage has highlighted a number of future challenges:
1) Many parameters need to be set correctly by the user/musician when working with a large group of Logos music robots. These parameters require a correct numerical value or range, a correct chronological order, etc. Anyone working with more than approximately five music robots will therefore need (testing) time to set all the parameters correctly. This problem has historically grown because the number of robots has increased, those robots have developed into a veritable orchestra, and because - over time - it became apparent that the (desirable) number of adjustable parameters per robot can vary considerably.
2) The practical implementation of (more or less) identical parameters sometimes differs from robot to robot. Such parameters include, for example, switching the robot on, the overall volume, or pitch-related parameters (to achieve, for example, quarter-tones, glissandos, alternative tunings, etc.). The same parameters may be assigned to a different controller (on a different robot); for example, pitch parameters may be adjustable on one music robot via pitch bend or MIDI controllers, but on another via aftertouch or the configuration of multiple (MIDI) channels (i.e. sending quarter-tones to a second MIDI channel).
3) The Logos music robots - and probably all automated musical instruments - are vulnerable to damage during use, just like traditional acoustic instruments. An organ's windchest can move up and down so rapidly, controlled by operating commands, that it is damaged or wears out much more quickly. Having a player piano play forty keys simultaneously at fortissimo exerts an extremely high force on the strings and soundboard, with a risk of damage (e.g. broken strings). Note repetitions that are too rapid can cause magnets and MOSFETs to burn out. The design of the music robots strikes a delicate balance between safety and opportunities for the user to experiment. In general, the Logos music robots are not 'consumer devices' intended for a broad audience, but rather prototypes designed for musicians and instrument makers with knowledge of digital music technology, mechanical musical instruments and music software (programming). This means that only the most urgent and essential safety procedures are built into the hardware and control systems of the music robots. This leaves plenty of scope for the musician to experiment with the music robots (which, indeed, has happened very often in the past). In practice, external musicians working with the robots have always been supervised by Logos staff members (such as Kristof Lauwers or Xavier Verelst). Years of experience and collaboration with dozens of musicians have shown that making safety procedures gradually adjustable can save time and effort. In the early stages, for example - when musicians are not yet fully familiar with the music robots - it can be useful not to experiment with all the parameters of a music robot just yet.
4) Some music robots have MIDI parameters that are used solely during the construction and development of the music robots. These parameters may be activated (unintentionally) by the user-musician.
5) Some software, particularly the more 'user-friendly' sequencers or DAWs, uses its own specific (non-customisable) variants of the 'General MIDI' protocol, which means that MIDI data (such as program changes or specific controllers) are sent without the user being aware of it. In fact, for refined, precise control of the Logos music robots, software is required that is based on programming languages, such as MAX/MSP, Pure Data or SuperCollider. For this reason, Logos's own GMT software has been used regularly in the past: GMT is more precise and more programmable than user-friendly DAW music software.
6) As mentioned, the construction of the Logos music robots is a work in progress. This means, amongst other things, that new versions, modifications and repairs have been made to the music robots (e.g. the range of a parameter is rescaled) or that the general configuration of the robot orchestra (e.g. the allocation of MIDI ports and channels) has been adapted to new requirements. It was impossible to predict in 1989 that the first music robot would, 35 years later, end up in a network comprising more than 85 robots.
7) The documentation for the music robots is extensive; for each robot, Godfried-Willem Raes has created a dedicated web page detailing its construction and the manufacturing process. There is also an overarching web page that explains, specifically for composers, how to use (the MIDI implementations of) all the music robots. In general, this documentation has proved to be an excellent starting point for many musicians wishing to use the music robots. However, Logos's experience with collaborating and resident musicians has also shown that - certainly in the initial phase - guidance from Logos staff (including Kristof Lauwers) remains necessary, partly because the documentation is sometimes too specialised and technical. Furthermore, the documentation for some robots is also interwoven with a historical account of their development process.
Before we describe how the GMT software is integrated with the music robots and the associated artistic repertoire, we will provide a brief general description of this software.
GMT is written in the PowerBasic programming language; users of GMT should be familiar with this programming language. GMT is primarily a programming and software environment designed and developed by Godfried-Willem Raes at the Logos Foundation. It originated from multitasking projects in DOS in the 1970s. The source code for GMT has historically been distributed in the public domain, mainly via the Logos website.
GMT gave, and continues to give, musicians the opportunity to work and compose algorithmically. This was certainly the case in comparison with commercial music software - sequencers or DAWs - during GMT's formative period, i.e. the period 1980–2000. In GMT, Raes created, amongst other things, libraries to devise algorithmic harmonisations and counterpoint. As of 2024, Godfried-Willem Raes and Kristof Lauwers are the two people who are familiar with and knowledgeable about the GMT software.
All MIDI settings for the more than 85 music robots and the test procedures for these instruments are built into GMT. This means that you can quickly try out a specific music robot with a specific parameter in GMT. If you want to test note repetitions on the piano robot, or check how to adjust the volume envelope on the horn robot, you can do so easily and listen to the results using this software. GMT also includes files and GUI interfaces for systematically testing (the parameters or components of) the music robots, to quickly identify problems with these robots. Finally, a MIDI player is also built into GMT to play back MIDI files as a demonstration of the music robots. This MIDI player (written by Kristof Lauwers) has a number of built-in procedures: MIDI data that is not relevant to a specific robot is omitted, and tracks can be given a name (of a specific robot), after which the MIDI ports and channels are automatically set correctly for that specific robot.
GMT also contains its own 'library' of 'tasks' for the radar, sonar and other interfaces that were built and used in Logos. Examples of these interfaces include 'Quadrada', 'Invisible instrument' and 'Picradar'. This library consists of modules that capture, analyse and convert the data from these interfaces; the GMT user (musician, composer, etc.) can then interpret these data (for gesture recognition), apply other algorithms to it and, finally, assign and send it to a music robot. In this way, for example, characteristics of moving performers (position, range, etc.) can be utilised artistically for musical dance performances. Examples of modules include the detection of rapid arm movements, or slow, walking-like movements involving the whole body, and the subsequent conversion of these into short rhythmic motifs.
To carry out simple tasks such as playing back files, there are compiled versions of GMT with a graphical user interface. If musicians wish to create their own compositions using GMT (algorithmically, interactively with the sonar or radar interface, etc.), they will need programming experience with PowerBasic.
In summary, these are the various ways in which GMT is integrated with the Logos music robots and the (artistic) repertoire surrounding them. In GMT:
• the settings for controlling the music robots are pre-programmed;
• test procedures are built in for those music robots;
• a few safety procedures are built into GMT, but most safety procedures are built into the programming of the micro-controllers. There are also a (very) small number of undocumented controllers that are integrated in GMT. Thus, these specific parameters can only be controlled from GMT. (text addition, 2026)
• there are built-in demonstrations (short musical works) for these robots;
• GMT interfaces with all manner of sensors and radar interfaces designed in Logos;
• there is a library for gesture recognition and associated musical composition and performance (primarily written by Godfried-Willem Raes);
• There are hundreds of (mostly algorithmic) compositions by Godfried-Willem Raes. These are works programmed in PowerBasic and then compiled in GMT. Some of these are interactive works involving music robots.
• There are around thirty original compositions by Kristof Lauwers, including a number of interactive works (often using radar or sonar interfaces). Some of these were eventually converted from GMT into MIDI files.
• Around ten co-productions, adaptations or arrangements created by Kristof Lauwers in collaboration with, or based on, the work of, amongst others, Earle Brown, Cornelius Cardew, Karlheinz Essl, Tom Johnson, Phill Niblock, Ellen De Nolf, W. A. Mozart, René Mogensen, Jelle Meander, Frederic Rzewski, and the Logos Web Strikes Back project.
GMT and the list above have also enabled Logos to give demonstrations and public school performances 'smoothly' in the past. Furthermore, creating interactive performances or installations with the robots could be done fairly quickly and efficiently, as it was always possible to draw on that existing list of GMT capabilities and libraries.
To complete this description of how the music robots are controlled, here is a brief summary of how the musicians work (with the robot orchestra): Logos artist G.-W. Raes uses GMT, as does Kristof Lauwers (though he also uses Pure Data or standard sequencer software); the majority of the musicians produce pre-recorded compositions in MIDI format for the Logos robots; these are played back via sequencer software (e.g. Sonar, Reaper, etc.). A smaller number of musicians create interactive, live compositions or improvisations in which the performance of the music robots is adjusted or altered in real time in one way or another. This is achieved using software such as MAX/MSP (by GamutInc, Nicola Hein, Sebastian Gramss, etc.), Pure Data (Hans Roels, Kristof Lauwers (in part)), SuperCollider (Jonas Runa) or Ableton Live (Bram Stadhouders, Marc Sinan).
Below, we propose a number of solutions that improve accessibility for users of the music robots whilst at the same time ensuring safety for the music robots. As a pioneer, Logos has built up a very large robot orchestra (with a very extensive accompanying repertoire) and is, in practical terms, one of the first to experience 'first-hand' how difficult it is to create a certain degree of uniformity in the use and control of music robots. If we look beyond this specific situation, a broader, cultural-technological question arises: how uniform can (or will?) music robots be? And: what protocol is desirable for controlling music robots in the future? It is presumably more realistic for Logos - as a pioneer in this field - to seek temporary, specific solutions, rather than attempting to resolve this broader issue once and for all.
These are possible solutions:
a)Create templates in which the main parameters for each music robot are correctly set. These are, in essence, MIDI templates suitable for playback in sequencer software. These templates need to be 'maintained' and updated whenever changes or revisions are made to the music robots. (Suppose two templates are created per robot - one for the basic parameters, and a second to demonstrate more sophisticated, complex control. This would then result in more than 170 templates.
b) Create sample patches and files in Pd, MAX or SuperCollider, in which all parameters of a Logos robot are correctly set and demonstrated. These files must also be 'maintained' and updated whenever changes or revisions are made to the music robots.
c) Rewrite and update the documentation, completely separating it from (the description of) the historical development process.
d) Create a new layer between the user (software) and the music robots. This middleware would, for example, use the Open Sound Control protocol, which works simply and transparently with the musicians' software programmes. The code for the music robots within this middleware would then be more readable for the user-musician.
e) With this middleware solution, the question arises: can we also transfer the safety procedures (to prevent damage to robot components) to this new 'middleware'? Or provide a basic safety procedure? A protocol such as Open Sound Control is merely a (music) networking protocol that allows you to make the commands more readable, but you cannot use it for programming. This raises questions: should this middleware be a programming environment (such as Java, for example), and is there a middleware solution that ensures both ease of use and readability for the user-musician whilst guaranteeing safety for the music robots? Ideally, this middleware would operate in both directions and also send 'feedback' from the robot back to the user, for example to issue a warning if that user is carrying out a risky experiment.
f) We are seeking advice from researchers, institutions or companies that also have expertise and experience in the development of music robots (e.g. the Karmetik Machine Orchestra at the California Institute of the Arts). Thanks to this advice, we hope to find solutions that will guarantee the openness and accessibility of music robots (for musicians) in the future.
Hans Roels