Instrument simulation challenges: cymbal (tier 2)#
This repository defines simulation challenges that approach a cymbal one feature at a time, and publishes the comparison of every registered solution at challenges/cymbal/site. It follows the same arrangement as the string and plate repositories: the model is defined in the continuum, solutions live in separate registered repositories, and the shared challenge-tools package scores them against a reference chosen from among the submissions.
Challenges#
| ID | Title | Deliverable |
|---|---|---|
| cymbal-flat-disk-v1 | Flat bronze disk struck with a drum stick, geometrically nonlinear (Saint Venant-Kirchhoff): radiated pressure | 6 s mono wav, 48 kHz, float32 |
| cymbal-bow-v1 (draft) | The same disk bowed into a shallow paraboloid, 25 mm rise: the effect of curvature alone | 6 s mono wav, 48 kHz, float32 |
The starting point is the simplest object that can sound like a cymbal: a flat, free disk of bell bronze with the diameter and thickness of a 16 inch crash, uniformly thick, struck near the rim by a short stick-like force pulse and radiating to a listener above it through the Rayleigh integral. The material model is Saint Venant-Kirchhoff, so the strain is exact and the response geometrically nonlinear; the material remains elastic. This is the model of the plate tier's second challenge applied to a disk with a harder, shorter strike, and it produces the pitch glide and broadband cascade that distinguish a cymbal from a struck plate. Thin-plate theories (von Kármán with or without in-plane inertia) are approximations to this model, and their error relative to a converged three-dimensional solution includes the modeling error of plate theory. Until such a solution is submitted, the reference is the best thin-plate solution and the reported errors measure only differences within plate theory; the results page says which it is.
Planned challenges#
The features of a real cymbal are added one at a time, each as a new challenge on the same material and strike, so that the effect of each on the sound and on the difficulty of the computation can be seen in isolation. In the intended order: a radial bow (drafted as cymbal-bow-v1: a shallow paraboloid, which couples bending and stretching even at small amplitude), a central bell (a spherical dome around the mounting hole, which stiffens the center and adds the ping), hammering (a pattern of local dents that breaks the axisymmetry and detunes the degenerate mode pairs), and a thickness that varies with radius (thinner at the rim). Curved and dented geometries also make the Cartesian-grid discretizations of the flat disk less natural, and polar or mapped grids are expected to appear among the solutions.
Each challenge lives in challenges/<challenge-id>/ and consists of a README.md, which is the authoritative specification, and a challenge.json with the parameters, output format, error measures, and the recommended grid for optional field exports in machine-readable form. A challenge is never changed once solutions exist for it; a corrected or modified model gets a new ID.
Solution repositories and the registry#
The repositories that take part in the comparison are listed in registry/solution-repos.json. To register one, open a pull request adding an entry (repository, branch, path of its solutions directory). A solution repository contains solutions/<challenge-id>/<submission-id>.json files following the submission schema, with wav files beside them or at URLs, and optionally field exports (about 40 MB each for this challenge, so git LFS or an external URL is advisable). challenges/cymbal-solutions is the first one and serves as an example.
The comparison workflow clones every registered repository at the head of its branch and runs on any push to this repository or when dispatched by hand (mochi workflow run .mochi/workflows/results.yml --repo challenges/cymbal). Nothing in the vault triggers across repositories, so a push to a solution repository is picked up at the next run here.
Scoring#
Every solution is compared with the reference under the two error measures defined in the challenge README, the relative waveform and spectrogram errors; the waveform error ranks. The reference is chosen automatically from the accuracy orderings that submissions assert about their own solutions, by the rule described in the string repository README and implemented in challenge-tools, with the same limitations. A challenge may override the choice by naming a solution in reference_solution in its challenge.json; this will be the natural thing to do once a verified three-dimensional solution exists.