midiviz

How commercial modelled violins get their sound

Research brief, 18 Oct 2026, for #034 (03_violin_sound.md is the wider survey). Question: what do Audio Modeling SWAM, Expressive E Soliste and Sound Magic Violin One do that our two physical models (strings/sound/bowed.js) do not?

None of the three publishes its internals. What follows comes from their manuals, their own technology pages, patents filed by the people behind SWAM, and reviews. Wherever a statement is an inference, it says so.

1. The three products

1.1 Audio Modeling SWAM Solo Strings (v3)

1.2 Expressive E Soliste (2025)

1.3 Sound Magic Violin One (free, 2025)

2. What they share

  1. A real body. All three treat the body as a separate, swappable component (Soliste’s 400 MB suggests large body data), and Samplemodeling patented a way to estimate one from recordings. A violin body has hundreds of resonances, and their density above 1 kHz is what makes wood sound like wood.
  2. No recordings in the source of the modelled strings. SWAM Solo Strings, Soliste and Violin One synthesise the string itself. Only Samplemodeling’s instruments (a different company) are built from samples. So a pure model can reach SWAM’s level; the gap is in how good the model and its body are.
  3. A model of the player. This covers transitions picked from interval, timing and velocity, randomness in bow and finger, assisted vibrato, and keeping the bow inside its playable window by feedback.
  4. Space and movement: early reflections, a room, microphone modelling, and small player movements that change the radiated tone over time.
  5. A pure model can still sound synthetic. SOS found Soliste not naturalistic in melodic playing, while SWAM is widely considered the most realistic modelled violin. Both are pure models, so the difference lies in their bodies, bow models and behaviour, which neither publishes.

3. Our physical models against that list

Ingredient SWAM / Soliste / Violin One #034 waveguide and source
Body Measured or estimated from recordings, selectable 10 signature modes + 42 random “dense” modes from 1 to 7.5 kHz per ear (Body in bowed.js), then a 13-band EQ fitted to VSCO. Far too few modes: likely the main cause of the hollow, “plasticky” tone.
Source micro-detail Modelled (bow noise, rosin, string resonance controls in SWAM) Pure model: 1.5 % rosin jitter on μs; a sawtooth plus gated noise
Bow kept playable Interactive BowPress (feedback) Feed-forward only: F ≥ 0.02·(Z/0.3)^1.5·v/β². Missed Helmholtz motion on 26 of 369 pitch × dynamic cases in our sweep when it was tuned (wrong octave or raucous); the test only asks for 85 %.
Behaviour Transitions from interval, timing and velocity; random bow and finger; dynamic transitions performance.js + humanize.js cover most of this already
String crossings in slurs Old string’s ring stopped on small intervals Force hands over within 12 ms; old string rings freely
Radiation and space Directivity, mic models, player movement, ER + room Static stereo (two random mode sets) + the #030 hall
Controls in mp–mf Advised Our default bow force targets the middle of the window, often bright and “biting”

4. What to change, in order

  1. A measured body. Two routes:
    • (a) Estimate it from recordings we already have, as the 2004 patent does: track each harmonic’s amplitude across the vibrato and glissando samples (VSCO “Arco Vib”, University of Iowa) to get the body’s magnitude response densely, then build a minimum-phase FIR of about 2,048 taps per ear. That costs one ConvolverNode, or a partitioned convolution in the worklet. Pérez Carrillo, Bonada, Pätynen and Välimäki measured violin radiation from bowed glissandi with exactly this kind of deconvolution (JASA 2011, Pérez PhD).
    • (b) Use the NBody hammer impulse responses (Cook and Trueman, Princeton, 1998): a violin measured at 12 microphone directions, per string (files). They carry no licence, so they would stay git-ignored like the TNUA and VSCO data unless the authors agree.

    Either route also gives directivity: crossfade slowly between directions to mimic player movement.

  2. Bow-pressure feedback (Interactive BowPress). In the waveguide, count slip events per period, which is cheap because we already know when the string slips. Two slips per period means a double-slip or wrong octave: raise the force. Irregular slips mean raucous: lower it. The fix should be smoothed over about 20 ms and limited to a few dB. This targets the wrong-octave and scratch artifacts directly.
  3. Richer modelled bow noise. Follow SWAM’s bow-noise, rosin and string-resonance controls: noise from the friction itself (shaped by slip speed and force), a second string polarisation, and torsion. Keep it all synthetic, as SWAM does. (Mixing in recorded attacks is the hybrid sampler’s job, engine 6.)
  4. Behaviour gaps: stop the old string’s ring on slurred crossings of small intervals; keep the default bow force lower in the window (mp–mf); add Vibrato Random and Random Bow as continuous slow noise rather than per-note offsets.
  5. Early reflections before the hall, at short delays and slightly coloured, so the dry model never sounds anechoic.

Items 1 and 2 are probably most of the audible gap; the others are refinements. Item 1 uses recordings only to measure the body (a filter), not as sound, so the engine stays a pure physical model like SWAM’s.

5. Bodies in #034, explained

What “the body” is

A bowed string on its own makes a fairly plain, buzzy tone, and it hardly makes any sound in the air: a string is too thin to push much air. It pushes on the bridge instead, and the bridge shakes the wooden box. The box (top plate, back, ribs, the air inside and the f-holes) radiates the sound you hear, and on the way it filters the string’s vibration. Its hundreds of resonances make some frequencies loud and others quiet: the air mode near 280 Hz, the main wood modes around 450–550 Hz, the “bridge hill” around 2–3 kHz, and a dense thicket of smaller peaks and dips above 1 kHz. That filtering is most of what makes a violin sound like a violin and not a synthesiser, and it is also why two violins sound different with the same strings and player.

In a physical model the body is exactly that: a filter between the bridge force the strings produce and the sound that leaves the instrument. The bodies on #034’s Timbre → Body menu are different answers to “where does the filter come from?”

About 50 resonances: 10 at the frequencies violin acoustics papers report for the signature modes, the other 42 at random frequencies and levels shaped like a bridge hill, then an EQ fitted to the VSCO recordings. A real body has far more resonances, and the random ones are in the wrong places. This is probably part of the hollow, “plasticky” tone.

Measured (Iowa)

A filter built from recordings of real violins, viola and cello instead of invented resonances. Nobody measured the instruments directly: the body is estimated from the University of Iowa recordings (strings/test/fit_body.js), the way the 2004 Tommasini–Lucato patent and Pérez Carrillo et al. (§4.1a) do it.

Limits: it captures only how loud each frequency comes out, not how the body rings over time (the phase is made up, minimum-phase). It also includes whatever the room and the microphone added to the Iowa recordings, and whatever our string does differently from a real one, since the fit is against our string.

Measured (Philharmonia)

The same method as the Iowa body, applied to a second set of real instruments: the Philharmonia Orchestra’s free sound samples (violin, viola and cello, chromatic sustained notes at pianissimo to fortissimo, strings/test/fit_body_philharmonia.js). Two things differ from Iowa:

Comparing the two estimates is a check on both. Each is a different player, instrument, room and microphone. Whatever they agree on is the violin family’s body; whatever they disagree on is the individual instrument or the recording.

Limits: the samples may be used freely but not redistributed “as is”, so the 171 MB download stays in the git-ignored strings/data/Philharmonia/; only the fitted curves are committed. The fit is against our string, so a model is refitted whenever the string model changes.

Measured (NBody)

NBody is a 1998 Princeton project by Perry Cook and Dan Trueman (ISMA 1998 paper, data). They measured a real violin directly, held by a player inside a 4-foot icosahedron of 12 microphones in a foam-lined chamber: they tapped its bridge next to each string with a small force hammer and recorded the response at all 12 microphones. Dividing what a microphone heard by the hammer’s force gives the body’s actual impulse response, its “ring”. Unlike the Iowa estimate it keeps the timing (phase), and with 12 directions it could later imitate the tone changing as a player moves.

strings/test/build_nbody.js downloads the takes, divides out the hammer for all four strike points, averages them, band-limits the result to 120 Hz–13 kHz (where the takes are well above their noise), and keeps 93 ms of response. Each ear’s tone is the average of all 12 directions, because a listener in a room hears a blend of every direction the violin radiates in. Each ear keeps the timing of one microphone (3 and 10, the loudest), so the two ears still differ. Using just those two microphones as they were made the violin about 7 dB too strong around 4 kHz, because they face the top plate. The response is matched in level to the Iowa body.

Limits:

6. Why SWAM’s Bow Pressure and Bow Position knobs keep moving, and automatic bowing in #034

What SWAM does

The moving knobs in SWAM’s demo videos are not a hidden “player” inside the engine. According to the SWAM Solo Strings manual (v2.1; the v3 manual is not public), the GUI shows the live value of each parameter, and four mechanisms move it:

So SWAM leaves the bow to the player’s controller. The realism in its demos comes from a person, or a programmed curve, moving pressure and position all the time.

What violinists do with the bow

Schoonderwaldt measured violinists with motion capture and a force sensor on the bow (PhD, KTH 2009):

What #034 does now

Automatic bowing (style.autoBow, the Auto bowing slider, default 1) moves the contact point and force inside every note, as a violinist does. Nothing has to be drawn or played on a controller:

The page shows the result as two live meters in SWAM’s style, Bow pressure and Bow position, plus a dashed contact-point trace under the force lane.

Bow-force brightness turned out to matter more than the automation itself. Our two string models barely changed their tone with bow force. From pianissimo to fortissimo, the Philharmonia recordings get brighter by a median 521 cents of spectral centroid on violin, 952 on viola and 162 on cello. Our waveguide got brighter by 15–35 cents and our source model by 40–80. Every dynamic had the same spectral shape, which is the “sawtooth” quality: a synth tone that only gets louder. Each string is now tilted above about 3·f0 by an amount that follows its bow force (TILT in bowed.js). The tilt is fitted per instrument and string model by strings/test/fit_tilt.js, to the mean of the Philharmonia and Iowa pp/ff brightening (violin 400, viola 633, cello 293 cents: the two sources differ by up to a factor of three, so neither alone is the instrument), and is neutral at mezzo-forte, so the measured bodies still fit.

Measured on sustained violin notes, slow tone movement (spectral centroid, 0.2–3 Hz, below the vibrato):

  brightness wander level wander
VSCO recordings (sustained notes, one bow) 83 cents 0.87 dB
before (static bow, no tilt) 2–5 cents 0.17 dB
automatic bowing + brightness tilt 40–43 cents 0.5 dB

That is about half of what the recorded player does, up from almost nothing.