Concert for the public transport orchestra in four movements

Performed by the collective of drivers of the Krasnodar Tram and Trolleybus Department

Live at orchestra.stranno.su

Any musical album (or separate track), is always a recording, an echo of once played, synthesized, sounded.

Any live performance is an echo of once conceived, rehearsed, learned.

Any live improvised performance is an echo just like the previous one, but a short one - only the time from decision to performance is reduced.

In any case, music is an echo of some thought.

A new project from DFAP now offers to listen as music not the found sounds of everyday life, but data about the movement of public transport. Each of the links below leads to a website that pulls in "live" data about the speed and coordinates of traffic, and runs an algorithm that interprets (sonification) that data.

I orchestra.stranno.su/microtonal_composition_in_quarter_tones
II orchestra.stranno.su/chorus_of_machines
III orchestra.stranno.su/shortly_before_the_end_of_war
IV orchestra.stranno.su/an_alarming_search_for_elusive_structures_in_the_vicinity_of_unison

The music album here is presented as a set of hyperlinks, the compositions have no fixed duration, the algorithm conducts the data and voices it right before your eyes based on information arising right now. Right at your device, be it a smartphone or a laptop, it is not a recording that sounds, but precisely a live improvised performance*.

At the time of publication of this text, the administration of the Krasnodar Tram and Trolleybus Department is not made aware of this project (forced collaboration), in connection with which the drivers of the transport do not suspect that every time they press the pedal of their car they control some other processes.

Approximately after 22:00 Moscow time the amount of traffic begins to decline dramatically, making the sound less dynamic and more sparse, so the night time is not recommended for listening.



* Randomness is some simplification, a concealment of a series of events that lead to a definite result; it is through concealment that a definite result turns into an indefinite one.

Truly random processes are considered to be quantum processes, or processes somehow related to microcosm, which postulate that it is fundamentally impossible to "look under the hood" of processes occurring at this level, and impossible to embrace them all at once (for example, Heisenberg uncertainty principle, which, simply put, states that the more precisely we calculate some values, the more others elude us).

In programming and cryptography, there is a term "pseudorandomness. After all, we understand that a machine cannot generate random numbers - it generates only what it is strictly instructed to generate. Therefore, a computer or a smartphone can only generate pseudorandom values: that is, some external process is taken, some mathematical operations are performed with it, which in a certain approximation numbers similar to random. For example, in most browsers, pseudorandom values are generated based on the current time (down to milliseconds) at which the method generating these values was called. Theoretically, we can predict any such value at any point in time. However, it is quite difficult to call the method at exactly the right millisecond to get the desired pseudorandom number. And in general, we understand that for those tasks where these numbers are generated, no one will simply do such calculations.

It follows that the computer generates very specific quantities, quite predictable and deterministic, but we call them random under some assumption.

Does the movement of public transportation occur at random? When we stand at a bus stop and see a vehicle pulling up, we think that it is the vehicle that "fell out" by chance; in fact, waiting at a bus stop is a game of roulette, at least until the "winning" route number, the one for which we came to the bus stop, comes up.

Although in fact we understand that all transport most likely moves according to a pre-formulated schedule and follows a more or less strict order, and if it does not - it is the specific circumstances on the road, traffic jams, accidents, breakdowns and so on.

That is to say, if you monitor the schedule and the situation on the road, the randomness is somewhat dissipated.

And if we imagine that we have a service that monitors transport using GPS/GLONASS signals and displays traffic on the screen, then completely random event can be transformed into a completely deterministic at the first glance at the screen (assuming, of course, that the service works correctly).

Continuing this line of reasoning, we can go to an extreme and say that in our everyday life there is no randomness in the original sense, but there is only pseudorandomness, and therefore aleatorics is impossible (at least, if it is not based on quantum processes, using hardware random number generators).

In one dissertation the following was found:
“Y. Xenakis equated the concepts of 'aleatorics,' 'chance,' and 'improvisation,' favoring the latter: "'aleatorics', in essence 'musical improvisation' means that the performer is left with a choice." In his opinion, "the expression 'aleatoric music' actually means improvised music. The use of the word 'aleatoric,' in its scholarly sense meaning 'accidental,' instead of improvisational, is totally wrong and expresses a false and sentimental position." But the term "improvisation" has a well-established meaning as the art of music-making, the creation of a work directly in the process of performing music. Improvisation in folk, jazz or oriental religious music may be conditioned by some context (artistic taste and experience of the performer, his skills, playing technique and knowledge of musical genres, styles, composing methods, finally, aesthetic principles), but is not predetermined by anyone but the performer himself. The improvisation of aleatoric music (for example, graphic or verbal scores) represents a special kind of performing art, which can rather be called a free interpretation of the author's idea. The term 'improvisation' itself cannot serve as a synonym for 'aleatorics.'"

However, it seems that this "performance context," genre, tradition, and cultural situation as a whole constitute together a "composer of composers," which, to a certain extent, predetermines the actions of the composer or improvising performer. Or, in more technical terms, a genre is a certain API, a set of properties, methods and ways of addressing them, a set of ready-made algorithms, by addressing which we "access" certain sounds.

In any case, no matter how strictly or freely we interpret the terms, no matter how much we reason about the nature of randomness or predetermination, we can always question the randomness of the random and the determinacy of the deterministic, and thus we can question the aleatoriness of any composition. The concerto for orchestra also finds itself in an intermediate position: on the one hand we get completely unpredictable behavior at first glance of the algorithm's work, on the other hand the order of its work is strictly defined, and the traffic is not so chaotic. However, the algorithm makes all the musical decisions at the last moment, just as the drivers who drive their cars make decisions "right now", focusing on the situation on the road. And although these decisions can be predictable in general, we cannot predict them precisely, and the time from the decision to its pronunciation is quite short, so we can call the Concerto compositions as improvisations with a certain degree of liberty.



Technical Description

The algorithm regularly receives data about the movement of public transport from a server in Latvia, which provides this data to several transportation services in several cities in Russia and the Baltic States, and read the data into several arrays, which contain information about the speed, type of transport, route and coordinates. Then, based on this data, markers of moving vehicles are drawn on the map.

In parallel, the algorithm generates an array of tone frequencies within a equally tempered scale:
- for the first part: from the small octave note D (146.8324 Hz) upwards in a quarter-tone scale (24 notes per octave);
- for the second part: from the note A of the contra-octave (55.0000 Hz) upwards in semitone scale (7 notes per octave);
- for the third part: from the note in A of the contra-octave (55.0000 Hz) upwards in an eighth-tone scale (48 notes per octave);
- for the fourth part: from the B note of the first octave (493.8832 Hz) upwards in 300-tone scale (300 notes per octave);

In the following, the algorithm will map each of the tones to a velocity in km/h such that the higher the velocity, the higher the tone.

The first two parts calculate the average traffic speed and monitor its change. If the average traffic speed in the city increases, the distance between tones over time decreases (tones are played more often). In case the average traffic speed decreases, the distance between tones increases (tones are played less frequently).

In the third and fourth parts, the distance between tones is fixed.

All issues related to transport data are handled by the entity (javascript method) transportSupervisor, which acts as a dispatcher, observing the traffic of each public transport salon in the city.

TransportSupervisor passes all this data to another entity, orchestraConductor, which performs the tasks of a conductor, a sound manager who makes the final decision about which sounds, in what order, of what duration and frequency will be played at each moment in the composition. Having determined the frequency of the tone and the duration to the next, the conductor passes this data to a third entity, the toneGenerator, whose task is to generate a fading sine wave within the specified parameters.

The salons whose tone is being played at the moment are highlighted on the map. A detailed description of all of the conductor's actions and a report on the movement of transport can be observed in the score, which is formed right during the performance.

(although it could be argued about score: if we proceed from the fact that the score is an algorithm of actions for extracting sounds, then the program code itself can be called a score, which determines the sound; on the other hand, the score can be understood as a record of notes that actually sounded in a particular sequence, which is in fact a textual documentation of the composition)

Technologies used: html, sass, js, Web Audio API, Leaflet + OpenStreetMap + Stamen.