Why not just use engine loops?

The simple solution would be to record an engine every few hundred RPM and switch or blend between loops.

I do not really want that. It always becomes a compromise: each recording already contains one exact RPM, one load and one particular engine state.

My first experiments were completely synthetic. I generated a combustion pulse — basically BUM — followed by an exhaust pulse — FUK — and passed it through simple resonances representing the engine and exhaust.

It worked, but it still sounded too much like a synthesizer pretending to be a diesel.

Using real engine events

The next approach was to record a real engine and use its individual sound events as building blocks.

The first profile comes from a Zetor 5501, an old water-cooled inline four-cylinder diesel.

From recordings made at several RPM levels, the program extracts many short real events:

  • combustion and mechanical knocks,
  • exhaust pressure pulses,
  • deeper exhaust body,
  • harder exhaust bark,
  • and other small irregular noises.

The sound is still generated in real time, but instead of generating an artificial BUM, the mixer uses an actual recorded engine pulse.

Each RPM region contains many different real samples, so the same perfect event is not repeated forever. Their decays overlap naturally, while the engine scheduler decides when the next cylinder fires.

The recordings provide the character of the engine. The program provides the timing and behaviour.

More than one engine

The Zetor is only the first profile.

The same idea should eventually cover different machines used on the layout, for example:

  • mining and heavy machinery, such as quarry dumpers and excavators,
  • road and city vehicles, such as trucks, buses and trams,
  • railway vehicles, locomotives and multiple units.

The aim is not a collection of generic engine sounds. Each vehicle type can have its own acoustic profile including engine, exhaust, cooling, transmission, hydraulics, electric traction, fans and other characteristic noises.

The final goal is to make the sound react to what the model is actually doing, not just to its speed.

A vehicle accelerating, cruising or working under heavy load should sound different even at similar RPM.

Why generate it on the Worker?

There is no need to stream audio over ESP-NOW.

The LowMaster can send only things such as:

  • direction,
  • target speed,
  • acceleration,
  • sound enable,
  • and possibly load or other state information.

The Worker already knows what the drive motor is doing, so it is the natural place to generate the matching sound.

The current PC application is mainly a listening and development tool. Once the profiles are good enough, the same mixer and compact sound data can run directly on the ESP32-C3.

Basic idea

This project sits somewhere between sample playback and a synthesizer.

It is not:

play a recording of an engine

and it is not:

generate an engine from tones and noise

Instead:

record a real machine, extract small characteristic sound events, and use them to generate a new vehicle sound in real time according to the actual movement and load of the model.

As usual, this is a fairly unnecessary amount of engineering spent on making tiny vehicles behave slightly more like the real ones.

Which is probably the fun part.