Projects on Benjamin Geer

Comparing the performance of SQL queries

Thu, 29 Jan 2026 18:25:18 +0100

I wrote a little Rust program, sqlstopwatch, to compare the performance of different SQL queries. I was inspired by the article Benchmarking SQL published by the jOOQ project, where they write the test code in SQL. I wanted something similar, but with a few additional requirements:

A command-line program with a simple TUI showing a progress bar.
The program should support PostgreSQL, MySQL, and SQLite.
It should read the SQL queries and test parameters from a configuration file specified on the command line.
It should print the results as a table in the terminal or save them as a CSV file that I can use to generate a chart.

The TUI was easy to make with Ratatui. To interact with the database, I used the async database library sqlx, which provides a bundled SQLite library.

I considered using TOML for the config file, but the file has to specify the database credentials. In testing environments, credentials may have to be loaded from environment variables or from files on a mounted file system, but TOML doesn’t support carrying out those sorts of operations. Moreover, you might want to generate a number of similar queries and compare them, as I did in this database optimisation project. Therefore, it’s better if the config file is a program in a scripting language. My exercise in writing an interpreter for a scripting language had given me a new appreciation for the Lua virtual machine. So the config file is a Lua script, which I find more convenient to write in Fennel, a Lisp dialect that compiles to Lua. Thanks to the mlua library, it was very easy to embed a Lua interpreter in the program, and to use Serde to convert Lua tables into Rust structs.

Writing a Bittorrent client in Rust

Thu, 15 Jan 2026 15:16:01 +0100

Overview #

To continue learning Rust, I decided to implement a client for Bittorrent, the communication protocol for peer-to-peer file sharing. The Bittorrent clients I’ve used have complex GUIs that seem to be designed for users who download and upload torrents all day, rather than for the occasional user like me, who just wants to get one file. And like many GUI applications, Bittorrent clients tend to accumulate files that take up disk space in obscure directories. I do many things in the terminal, and when I need to download a file, my reflex is to use curl. So I thought, why not make something like curl for Bittorrent? Thinking about curl’s progress meter, it occurred to me that I could do something similar with the TUI library Ratatui, which I’d been wanting to try.

A Bittorrent client seemed like a good opportunity to learn about asynchronous programming in Rust. I had read a lot of criticism of Rust’s async, but I found it pleasant to work with (using the Tokio runtime), and certainly more comfortable than the comparable frameworks that I’d used in Scala (Akka and Cats Effect). I particularly like that an async function can be run in an existing task or in its own task, unlike Scala’s Future, which is assigned a thread and starts running as soon as it’s constructed. Rust’s approach seems more conducive to refactoring and maintainability. At the same time, I’m glad not to have to deal with the complexity of using monads as in Cats Effect.

The result is Sayaca, named after a South American bird that plays an important role in seed dispersal (in Bittorrent terminology, ‘seeding’ means uploading).

Design #

My first task was to implement a parser and formatter for Bencode, the data format used in the Bittorrent protocol. Conceptually it’s similar to JSON, but it’s designed for binary data rather than text. I wanted to try using a parser combinator library, and had no trouble implementing the parser using nom. Since I wanted to be able to serialise and deserialise Rust structs as Bencode, I added Serde support. I’ve published the resulting crate as bside.

The main difficulty in designing the client was the messy state of the Bittorrent specifications. There are ambiguities (the word ‘piece’ means two different things) and implementations have diverged from the specs (e.g. peer IDs are not used to identify peers). A great deal of knowledge about the protocol is not in the official specs, but in other documents scattered around the Web. There is a long list (not updated since 2018) of draft protocol extensions that are supported by many clients. A so-called encryption extension (which actually seems to describe a type of obfuscation) seems to be widely implemented, but as far as I can tell, since 2023, its specification has been preserved only in the Internet Archive’s Wayback Machine. There is a draft BitTorrent Protocol Specification v2 (not updated since 2017), which attempts to correct some of the original protocol’s flaws, such as its reliance on the SHA-1 hash function (which has not been considered secure since 2005). I could have wandered for a long time in a labyrinth of documents and in the source code of existing clients. To keep things simple, I decided to implement only the original BitTorrent Protocol Specification and the IPv6 tracker extension.

When saving data to disk, a Bittorrent client should perform well with large files, be able to interrupt a download and resume it later (which means that it has to note which pieces have been downloaded), and handle torrents that include multiple files. To meet these requirements, and to keep things transparent for the user, I chose to save downloaded data in an intermediate file (with the extension .sayaca), in the same directory where the completed file(s) will be saved. The intermediate file contains a bit field indicating which pieces have been downloaded (the same bit field that we have to send to peers anyway). Sayaca uses memory mapping to read and write this file; this should provide good I/O performance with large files. When the download is complete, it copies the data from the intermediate file into the destination file(s), and the intermediate file is deleted on exit if it is no longer needed.

Since a Bittorrent client is I/O-bound, I decided to use an event-driven architecture in which one task does most of the work, as in Redis. This main task delegates all the network I/O to other tasks, which it communicates with via channels. This was simple to implement, and had the advantage of making it easy to write unit tests for the main task.

Much of the work that a Bittorrent client does amounts to a sort of bookkeeping. In Sayaca, this job is the responsibility of the Bookkeeper. For example, in the recommended algorithm for selecting file pieces to request, the client tries to request the rarest pieces first. This requires a data structure that keeps track of the pieces that each peer has, as well has how rare each piece is, among other things. This can be done in different ways; I chose to use an ordered map, ordered by rarity, to store the IDs of pieces and the sets of peers that have them. The Bookkeeper can then easily find a piece, randomly chosen from among the rarest pieces, along with a randomly chosen peer that has that piece and is accepting requests from us. Thus, much of the client’s work involves updating the Bookkeeper when new information arrives and querying it to find out what to do next.

I like TUIs, and it was easy to make a simple one with Ratatui. But since the client is a library that communicates with its UI via channels, it would be straightforward to wrap the client in a different UI, e.g. a more accessible CLI.

Alternatives to this approach #

I chose to use Tokio because I wanted to learn about it and about async, but I think the program probably wouldn’t have been very different if I had used threads instead, with the same communication via channels.

Writing a virtual machine in Rust

Sun, 12 Oct 2025 00:00:00 +0000

Overview #

To help me learn Rust, I decided to implement an interpreter for Lox, the scripting language in Robert Nystrom’s book Crafting Interpreters. I’ve been interested in scripting languages that are designed to be embedded in applications, and this seemed like a good way to learn more about how such languages are made.

Nystrom’s book walks you through two different implementations of the interpreter: a tree-walk interpreter in Java, and a bytecode virtual machine in C. I was more interested in the bytecode VM. Over the years, I’d written a couple of tree-walk interpreters, starting with Apache FreeMarker, as well as an optimising source-to-source compiler with type inference. But I hadn’t implemented a bytecode VM yet. The idea of it brought back good memories of doing assembly-language programming on the Apple II when I was fifteen years old. The instruction set for Nystrom’s virtual machine is simpler than the instruction set of the Apple II’s Motorola 6502 CPU, but the basic idea is the same. So I skipped the part of his book about the tree-walk interpreter and went directly to the part about the bytecode VM.

The result is OrganicLox. The design is broadly similar to the one in the book, but I’ve tried to write idiomatic Rust, with reasonable performance and no unsafe code. Functionally, OrganicLox should be identical to Nystrom’s clox: at least, it passes his 246 automated tests.

I decided against writing my own garbage collector, because everyone seems to agree that garbage collectors are particularly difficult to implement in Rust. To keep things simple, I used reference counting instead (via Rc). On the main branch, this means that cycles of object properties won’t be collected. On the with_dumpster_gc branch, I’ve replaced Rc with the dumpster crate, which uses reference counting but also deals with cycles.

My favourite parts #

I liked this book very much: Nystrom’s clear explanations, useful illustrations, easygoing writing style, and humour made the book a pleasure to read.

For me, some of the most interesting parts of his design, which draws heavily on the design of the Lua VM, involved the implementation of local variables and closures in a stack-based VM. I enjoyed learning that the compiler associates local variables with specific positions on the stack, so the VM only needs to know about stack positions, not about the variable names they’re associated with.

The implementation of upvalues, the variables that are captured by closures (and may need to be heap-allocated as a result), was tricky to get right. While fixing a bug, I was delighted to realise that a recursive call to a function defined in a local scope requires the function’s closure to be one of its own upvalues.

What I wished for #

Nystrom alternates between top-down and bottom-up explanations. The bottom-up explanations made it more difficult to translate his design into Rust, since I had to guess where he was going. Several times I had to refactor a lot of code because I had guessed incorrectly. Since implementing Lox in all sorts of programming languages seems to be a popular exercise, it would have been helpful to have more high-level notes about the design.

It was fun to learn about Vaughan Pratt’s top-down operator precedence parsing technique and to see that it’s actually possible to generate bytecode without first building an AST. But perhaps it would have been more useful to produce an AST and learn something about writing a second pass to optimise the bytecode.

Performance #

The main optimisation I did at the outset was to have the scanner intern all identifiers (using string_interner), so neither the compiler nor the VM need to do any string comparisons on identifiers.

After finishing Chapter 24, I spent a bit of time looking at performance, following the advice in The Rust Performance Book. I ran benchmarks with criterion, did some profiling with perf and hotspot, adjusted the build configuration, and inlined some functions.

I then looked at some other Rust implementations of Lox, and noticed that everyone seems to have found it difficult to approach the performance of Nystrom’s clox, and that the implementations that succeeded in doing so contained a lot of unsafe code, which I wanted to avoid. I highly recommend Manuel Cerón’s blog post about his impressive, determined, and partly successful attempt to match the speed of clox in Rust by writing more and more unsafe code.

For comparison, here are the results of some of Nystrom’s benchmarks run on these implementations:

Nystrom’s clox
The safe version of Cerón’s loxido
The unsafe version of loxido
OrganicLox with Rc
OrganicLox with the dumpster garbage collector

OrganicLox with Rc is two to four times slower than clox, which is perhaps in the typical range for interpreters written in Rust compared to interpreters written in C. The version with dumpster is much slower. It seems clear that a fast garbage collector is essential for a high-performance VM.

How much do these differences matter? Benchmarks are designed to simulate extreme scenarios, e.g. by using long loops or deep recursion, or by creating a lot of work for the garbage collector, so they’re not necessarily representative of real use cases. The scripts run by applications with an embedded interpreter are often short and do very little work. We might get a more realistic idea of how a VM performs in such a scenario by running Nystrom’s integration test suite, which runs 246 short Lox scripts and checks their output. Here’s a comparison:

In an application where every CPU cycle counts, the differences in performance between these different implementations could be very significant. But in other use cases, they might not be.

Alternatives to this approach #

It’s tempting to try adding a just-in-time compiler (JIT) to improve the performance of the interpreter, either by writing one from scratch or by using an existing backend like LLVM or Cranelift. Examples in Rust include Roto and Dora. But even if you do that, it’s not easy to achieve high performance. In these benchmarks, Python’s new JIT has no measurable effect on performance (see also these Dora benchmark results).

That’s one reason to consider using an existing interpreter that already has years of engineering invested in it, instead of creating a new one. Lua is one popular option, but it isn’t fast enough for some applications. The widely used LuaJIT VM is an order of magnitude faster than the standard Lua VM for some use cases, but it’s a tracing JIT, which has advantages and disadvantages. The Lua developers have an interesting paper in which they discuss the limitations of this approach, and propose a different solution (an additional statically typed language, a bit like Cython).

For some use cases, if embedded scripts don’t do much work, their performance might not be critical. If they do so much work that their performance is insufficient, another option is not to embed an interpreter at all. Cloudflare, which had invested heavily for over 20 years in scripts using LuaJIT embedded in OpenResty, recently replaced them with Rust code.

Calculating centrality indices with the Paris public transport network

Fri, 29 Aug 2025 00:00:00 +0000

I thought it would be interesting to try some basic network analysis of the Paris métro (rapid transit) and RER (commuter rail) systems, starting with some centrality indices. These are metrics that rank the nodes in a graph according to their importance, for some definition of importance. For example, in a transport network, the centrality of a station could give an indication of the likelihood that passengers will pass through that station as part of their itinerary. A public transport authority could use this information to gauge how inconvenient it would be if particular stations were closed, e.g. because of flooding or maintenance, and to help it identify the most effective ways of improving the resilience of the network. Here I’ll use Python, networkx, and SQLite.

Constructing the graph #

Here I’ve chosen to combine the métro and RER into a single graph. The first challenge is to construct this graph as an edge list and a node list. The agencies that manage the Paris public transport networks don’t provide such a dataset, but they do provide a GTFS dataset representing the train schedules for the next 30 days. (Thanks to Oliver Blanthorn for pointing this out.) The GTFS data represents the trips (sequences of stops) that trains are scheduled to take along their routes (métro or RER lines). To construct the edge list for the network, we can traverse each trip, storing an edge between each stop and the next one. Some trips go in one direction, others go in the opposite direction, and many don’t cover the whole line, but by traversing them all, we should build up a complete directed graph of the network. We’ll have to traverse about 64,000 trips, containing a total of nearly 1.5 million stops, and a lot of the data will be redundant for our purposes, but this doesn’t matter as long as we can process it in a reasonable amount of time.

We therefore have to implement an ETL (Extract, transform, load) process. I wrote a shell script that downloads the GTFS data, as well as several files from a dataset called Référentiel des lignes de transport en commun d’île-de-France, which we will also need. Since all these files are in CSV format, and use unique identifiers to link together the data in different files, it will be easier to work with this data if we use a relational database. In this shell script, I import the necessary files into an intermediate SQLite database, and create some database indexes to speed up the queries in the transformation step. This takes about 21 seconds on my laptop, and the size of the resulting database is 2.1G.

Finally, I’ve written a Python script for the transform and load phases. It reads the intermediate database and builds the output database, which just contains a table of edges and a table of nodes. Since the output database is small (132K), the script creates it in memory for better performance, and writes it to disk when it’s complete. This script takes about 8 seconds to run.

In the Référentiel, links between the métro and and RER networks are represented by zones de correspondance and pôles d’échange, which can include multiple stations connected by corridors. To include these relations in the graph, I’ve chosen to add edges between all the stations in the same group.

In the output database, the graph is a directed multigraph, because two stations can be connected by more than one line. In such cases, we can see those two stations as having a stronger connection than two stations connected by only one line. Other things being equal, more lines mean more passengers travelling between those two stations. We’ll keep this information about mutiple edges when we do our calculations.

Drawing parts of the graph #

First let’s draw some of the data to see if it looks correct. We can write a function that draws a transport network graph. Here we don’t care about the geographical positions of the stations, we just want to see that we have the right stations with the right links between them. To help us see which line is which, we can use the colours defined for the transport network map, which are given in the GTFS dataset, plus black for the edges I added for the zones de correspondance and the pôles d’échange.

%config InlineBackend.figure_formats = ['svg']
import sqlite3
import pandas as pd
import networkx as nx
import numpy as np
import matplotlib.pyplot as plt
import itertools as it


def draw_graph(G, title, height, label_x_offset):
    plt.figure(figsize=(12, height))
    plt.margins(x=0.18, y=0)
    plt.title(title)

    pos = nx.nx_agraph.graphviz_layout(G, prog="dot")

    # See https://networkx.org/documentation/stable/auto_examples/drawing/plot_multigraphs.html
    connectionstyle = [f"arc3,rad={r}" for r in it.accumulate([0.15] * 4)]

    nx.draw_networkx_nodes(G, pos, node_size=30, node_color="#000000")

    edge_colors = [
        f"#{G[source_node_id][target_node_id][edge_key]["route_color"]}"
        for source_node_id, target_node_id, edge_key in G.edges
    ]

    nx.draw_networkx_edges(
        G, pos, edge_color=edge_colors, connectionstyle=connectionstyle
    )

    label_pos = {
        node_id: (node_pos[0] + label_x_offset, node_pos[1])
        for node_id, node_pos in pos.items()
    }

    text = nx.draw_networkx_labels(
        G,
        label_pos,
        labels=nx.get_node_attributes(G, "node_name"),
        horizontalalignment="left",
        verticalalignment="bottom",
        font_size=6,
    )

    for _, t in text.items():
        t.set_rotation(15)

Let’s try it with the métro lines 1 and 4, and the RER A:

DATABASE = "../../../notebook-data/paris-rail-data/paris-graph.db"

conn = sqlite3.connect(f"file:{DATABASE}?mode=ro")

nodes = pd.read_sql_query(
    """select distinct
        nodes.node_id, nodes.node_name
    from nodes
    inner join edges on
        nodes.node_id = edges.source_node_id or
        nodes.node_id = edges.target_node_id
    where
        (edges.route_type = 1 and edges.route_name = '1') or
        (edges.route_type = 1 and edges.route_name = '4') or
        (edges.route_type = 2 and edges.route_name = 'A') or
        (edges.route_type is null and
            (edges.route_name = 'PdE Châtelet - Les Halles' or
            edges.route_name = 'ZdC Gare de Lyon'))""",
    conn,
    index_col="node_id",
)

edges = pd.read_sql_query(
    """select * from edges where
        (edges.route_type = 1 and edges.route_name = '1') or
        (edges.route_type = 1 and edges.route_name = '4') or
        (edges.route_type = 2 and edges.route_name = 'A') or
        (edges.route_type is null and
            (edges.route_name = 'PdE Châtelet - Les Halles' or
            edges.route_name = 'ZdC Gare de Lyon'))""",
    conn,
).replace({np.nan: None})

G = nx.from_pandas_edgelist(
    edges,
    source="source_node_id",
    target="target_node_id",
    edge_attr=True,
    create_using=nx.MultiDiGraph(),
)

node_attributes = nodes.to_dict(orient="index")
nx.set_node_attributes(G, node_attributes)

draw_graph(
    G,
    title="Métro lines 1 and 4 and the RER A",
    height=20,
    label_x_offset=6,
)

That looks correct.

Plotting results #

The centrality functions in networkx return a dictionary whose keys are node IDs and whose values are centrality scores. Let’s define a function that takes such a dictionary and plots a bar chart of the top 25 stations in descending order of centrality.

def centrality_chart(centrality_dict, title):
    names_and_scores = [
        (node_attributes[item[0]]["node_name"], item[1])
        for item in centrality_dict.items()
    ]

    top_25 = sorted(names_and_scores, key=lambda t: t[1], reverse=True)[:25]

    top_25_df = pd.DataFrame(
        top_25,
        columns=["Station", "Centrality score"],
    ).set_index("Station")

    ax = top_25_df.plot.barh(title=title)
    ax.invert_yaxis()

Degree centrality #

First let’s read the whole graph:

nodes = pd.read_sql_query(
    "select * from nodes",
    conn,
    index_col="node_id",
)

edges = pd.read_sql_query(
    "select * from edges",
    conn,
).replace({np.nan: None})

conn.close()

G = nx.from_pandas_edgelist(
    edges,
    source="source_node_id",
    target="target_node_id",
    edge_attr=True,
    create_using=nx.MultiDiGraph(),
)

node_attributes = nodes.to_dict(orient="index")
nx.set_node_attributes(G, node_attributes)
print(f"Loaded {len(G.nodes)} nodes and {len(G.edges)} edges.")

Loaded 563 nodes and 1363 edges.

The simplest centrality index is degree centrality: for each node, we can count its inbound links (for in-degree centrality) or its outbound links (for out-degree centrality), and normalise the result by dividing by $n - 1$, where $n$ is the number of nodes. In our case, the results are the same for in-degree and out-degree centrality.

1
2

in_degree_centrality_dict = nx.in_degree_centrality(G)
centrality_chart(in_degree_centrality_dict, "In-degree centrality")

We can see immediately that the stations with the highest scores are mostly métro stations rather than RER stations. One possible explanation could be the apparently more radial structure of the RER network compared to the métro. Besides being located on more than one line, several of these stations (such as Havre-Caumartin) belong to a pôle d’échange.

Eigenvector centrality #

With eigenvector centrality, each node gets a score that is proportional to the sum of the scores of its neighbours. This way, a node can get a high score by having many neighbours and/or by having high-scoring neighbours. Given an undirected graph of $n$ nodes, for a node $i$ whose set of neighbours is $M(i)$, the eigenvector centrality $x_i$ is defined as

$$ x_i = \frac{1}{\lambda} \sum_{j \in M(i)} x_j $$

where $\lambda$ is a constant. We can rewrite this equation using the network’s adjacency matrix $A$, in which $a_{ij}$ is 1 if there is an edge that links nodes $i$ and $j$, and 0 otherwise:

$$ x_i = \frac{1}{\lambda} \sum_{j = 1}^n a_{ij} x_j $$

This is equivalent to

$$ \mathbf{x} = \frac{1}{\lambda} A\mathbf{x} $$

where $\mathbf{x}$ is a vector whose elements are the centrality scores. We can write this as

$$ A\mathbf{x} = \lambda\mathbf{x} $$

which means that $\lambda$ is an eigenvalue of $A$ and $\mathbf{x}$ is the corresponding eigenvector. Given the eigenvalues and eigenvectors of the matrix, choosing the appropriate eigenvector is simple, because (according to the Perron–Frobenius theorem), for a matrix (like the adjacency matrix) that has no negative elements, only the eigenvector corresponding to the largest eigenvalue can be chosen to have no negative elements. With a directed graph like our transport network, we can choose a left eigenvector or a right eigenvector. Usually the left eigenvector is chosen (and this is what networkx does), so that a node’s score is based on its inbound edges rather than its outbound edges. This doesn’t make much difference in our case, though, because nearly every inbound edge in our network has a matching outbound edge.

When eigenvector centrality is used with a directed graph, the graph must be strongly connected. This is true of our transport network, because every station is reachable from every other station:

`1`	`nx.is_strongly_connected(G)`

True

Here we use the networkx.eigenvector_centrality_numpy function, which first constructs the adjacency matrix. In a directed multigraph such as this one, if there are $n$ edges in the same direction between two nodes, networkx represents them as the value $n$ in the matrix, which is equivalent to a single edge with weight $n$. It then gets the relevant eigenvector, and returns a dictionary containing each node ID and the corresponding element of the eigenvector.

1
2

eigenvector_centrality_dict = nx.eigenvector_centrality_numpy(G)
centrality_chart(eigenvector_centrality_dict, "Eigenvector centrality")

If we compare these results to the degree centrality results, we can see that Havre-Caumartin, which is in the middle of the six-station Paris Saint-Lazare - Opéra pôle d’échange, gets a higher score because it’s adjacent to the two highly-ranked stations Saint-Lazare and Opéra. Several other stations, such as Saint-Augustin, Auber, and Haussmann Saint-Lazare, also get higher scores for the same reason.

Betweenness centrality #

Betweenness centrality counts the number of times a node is on one of the shortest paths (i.e., those that pass through as few nodes as possible) between each pair of other nodes. For a node $v$, it is defined as

$$ c_B(v) =\sum_{s \neq v \neq t} \frac{\sigma(s, t|v)}{\sigma(s, t)} $$

where $s$ and $t$ are any other nodes in the network, $\sigma(s, t)$ is the number of shortest paths from $s$ to $t$, and $\sigma(s, t|v)$ is the number of those paths that pass through $v$. In a transport network, a station with a high value for $c_B(v)$ is one that many passengers are likely to pass through if they choose one of the shortest paths to their destination.

1
2

betweenness_centrality_dict = nx.betweenness_centrality(G)
centrality_chart(betweenness_centrality_dict, "Betweenness centrality")

Most of the stations on this list are RER stations rather than métro stations, which makes sense, because the RER covers more distance between stops, so if the same journey can be done via métro or via RER, the shortest path will usually be via RER. It’s not surprising to see Châtelet les Halles at the top of the list, given its geographically central location and the large number of lines that pass through its pôle d’échange. It also looks like there are other configurations that can give a station a relatively high rank. For example, Juvisy is on a long section of the RER C where few stations have connections to other lines, and it connects to a similar section of the RER D, so it seems likely that many shortest paths have to pass through it.

Conclusion #

This has just been a brief exploration of a few centrality indices for this network, with some examples of how different definitions of a node’s importance result in different rankings. All the scripts used here can be found in this blog’s Git repository, along with the Jupyter notebook from which I generated this page. Please contact me if you have any questions or suggestions.

The Sound of Crying

Thu, 06 Mar 2025 00:00:00 +0000

In 2024 I did the English subtitles for the short film Mal partum (English title: The Sound of Crying), a beautiful documentary about postnatal depression. Émilie D. used her personal experience to make a film that provides practical knowledge that we can all use.

كوكبنا

Fri, 20 Sep 2024 15:00:00 +0000

An Arabic-language podcast that I started in 2021 on ecology, migration, and inequality, and would like to continue someday: كوكبنا.شبكة.

Tondauer

Fri, 20 Sep 2024 14:00:00 +0000

In 2020 I started a project called Tondauer, to make Creative Commons licensed editions of sheet music. It happened because of the Covid-19 lockdown that year: I was learning to play Felix Mendelssohn’s Prelude Op. 104a, No. 2 (MWV U 123), because it suited my mood of restless frustration at the time.

I started with a 19th-century edition that could be downloaded for free. Then I bought an edition with fingerings, and wondered why it had different notes. I looked in vain for the composer’s manuscript, but found only an earlier draft. I had been reading R. Larry Todd’s biography of Mendelssohn, so I emailed him to ask if he knew where the manuscript of the final version was, and he replied that it hadn’t been found. This meant that the only sources were the first editions, which were published after the composer’s death.

I had learned something about how critical editions are made while working in the field of digital humanities. So I decided to make my own critical edition. Over several months, as libraries and archives gradually reopened, I got digital reproductions of the first German and British editions. The two editors had worked together to publish them simultaneously, but they didn’t have the same notes, either. In my edition, I tried to make a plausible explanation of what had happened, and reconstruct the composer’s intentions as well as possible. In the end I tried to make the edition I wished I had had, and added fingerings with the help of Penelope Roskell.

More recently I’ve been working with musicologist Florence Launay on editions of forgotten works by female composers, starting with Armande de Polignac’s Preludes for Piano, which had survived only in a single copy of the first edition, preserved by her descendants. Florence had photocopied it, and pianists had been recording the pieces using photocopies of that photocopy. Now that we’ve published a corrected edition with Florence’s preface, I hope more pianists will enjoy playing these Preludes.

SocioResources

Fri, 20 Sep 2024 13:00:00 +0000

My old blog (2013-2021) on the sociology of autonomy and the autonomy of sociology.

أبحاث لفتت نظري

Fri, 20 Sep 2024 12:00:00 +0000

My old Arabic blog (2009-2014) on which I summarised research that I thought was interesting: أبحاث لفتت نظري.