# Shake&Tune: a Klipper plugin that turns resonance measurements into input shaper settings

> Shake&Tune is a Klipper plugin that runs the accelerometer measurement, plots the results and produces the input shaper filter recommendation in one workflow, so you do not have to interpret raw frequency response curves by hand. It installs over SSH on the printer, works on any Klipper machine rather than only Klippain ones, and its own configuration is long because every measurement setting is exposed.

**Frix-x/klippain-shaketune** — Klipper streamlined input shaper workflow and calibration tools

- Repository: https://github.com/Frix-x/klippain-shaketune
- Stars: 1,184 · Forks: 163
- Language: Python
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/frix-x-klippain-shaketune

## What the plugin replaces in the Klipper workflow

Shake&Tune is a Klipper plugin from the Klippain ecosystem, and its stated purpose is to create insightful visualizations that help you troubleshoot your mechanical problems and to give you tools to better calibrate the input shaper filters on your 3D printer.

That second half is the interesting part. The Klipper documentation already describes how to measure resonances with the accelerometer and how to run the shaper calibration, and the official measuring resonances page is the reference the plugin points you to for the hardware side. What the plugin adds is the analysis and the presentation: you get graphs that show what the machine is doing and a recommendation for the filter, rather than a set of numbers you have to interpret.

The scope boundary is stated explicitly, and it is a generous one. It can be installed on any Klipper machine and is not limited to those using the full Klippain. So you do not have to adopt the wider Klippain project to get the visualisation and calibration tooling. The Klippain ecosystem is the origin, not the requirement.

The primary language is Python, the licence is GPL-3.0, and the author is Félix Boisselier. The project describes itself as Klipper streamlined input shaper workflow and calibration tools, which is the whole pitch in one phrase: it collapses several separate steps into one.

The repository layout backs that up. There is a shaketune/ package directory, an install.sh at the root, a ci/ directory, a docs/ directory that the README points to as the detailed documentation, a requirements.txt and a pyproject.toml, and a system-dependencies.json file whose presence suggests the installer can pull in the system packages the analysis needs.

## The install is a wget piped into bash, and the accelerometer comes first

The installation section lists three steps, and the order matters.

The first step is a prerequisite rather than an action. Be sure to have a working accelerometer on your machine and a [resonance_tester] section defined, and you can follow the official Measuring Resonances Klipper documentation to configure it. The plugin measures, it does not measure for you, so without an accelerometer and that configuration section in printer.cfg, none of the macros will do anything useful.

The second step is the install itself, run over SSH on your printer:

```bash
wget -O - https://raw.githubusercontent.com/Frix-x/klippain-shaketune/main/install.sh | bash
```

Piping a remote script into a shell is the standard Klipper plugin installation pattern, and Klipper itself is a Linux system running on the printer's board, so a shell is always available. The install.sh file is in the repository, so you can read what it does before running it, which is worth doing for a script that executes on the machine that runs your prints.

The third step is configuration, and it is the least obvious. You append a [shaketune] section to your printer.cfg file and restart Klipper. The shipped block is entirely commented out, so the defaults apply unless you change something:

```
[shaketune]
# result_folder: ~/printer_data/config/ShakeTune_results
# number_of_results_to_keep: 10
# keep_raw_data: False
# show_macros_in_webui: True
# timeout: 600
# measurements_chunk_size: 2
# max_freq: 200
# dpi: 300
```

The defaults are documented inline, which is unusual and useful, because each of these is a real trade-off.

The result folder is where processed results are stored, and it is created automatically if it does not exist. number_of_results_to_keep is 10, and once that count is exceeded older results are automatically deleted to free up space on the SD card. That default tells you something about the hardware: a printer's SD card is small and the plugin is written with that in mind.

keep_raw_data defaults to False, and setting it to True stores both the processed graphs and the raw accelerometer .stdata files. The comment asks you to always attach them when reporting any issue on GitHub or Discord, which tells you the raw data is what a maintainer needs to diagnose a problem and the processed graphs alone are not enough.

## The configuration options that actually change the behaviour

The second half of the configuration block is where the interesting decisions live, and the comments explain the reasoning for each.

timeout is 600 seconds, the maximum processing time Shake&Tune is allowed for generating graphs from a .stdata file. Ten minutes should be more than enough in most cases, but on slower hardware such as older SD cards or low-performance devices you should increase it to prevent timeouts. This is the setting that most often needs adjusting, because a graphing operation that exceeds its budget is killed partway.

measurements_chunk_size is 2, and the explanation is the most specific in the whole file. Each Shake&Tune command uses the accelerometer to take multiple measurements, and by default Shake&Tune writes a chunk of data to disk every two measurements, and at the end of the command merges these chunks into the final .stdata file for processing. The value 2 is described as a very conservative setting to avoid Klipper Timer Too Close errors on lower end devices with little RAM, and it should work for everyone. If you are using a powerful computer, you may wish to increase it to keep more measurements in memory, for example 15 to 20, before writing the chunk and avoiding stressing the filesystem too much.

That is a two-sided setting. Low values keep memory usage down, which protects the Klipper process from timing out on a board with little RAM, at the cost of more writes to the SD card. High values reduce the number of writes, which is faster and less stressful to the filesystem, at the cost of holding more data in memory. The plugin is careful to describe the default as one that works for everyone rather than an optimum, and to say to avoid touching it unless you know what you are doing.

max_freq is 200, the maximum frequency at which the calculation of the power spectral density is cut off. The default is said to be fine for most machines and accelerometer combinations.

dpi is 300, controlling the resolution of the generated graphs. The comment is a bit jokey about it, noting that 300 dpi was optimised to strike a balance between performance and readability and that graphs are clear without using too much RAM to generate them.

show_macros_in_webui defaults to True. Mainsail and Fluidd do not create buttons for system commands, which are macros that are not part of the printer.cfg file, and this option allows Shake&Tune to inject them into the web interface at runtime. Setting it to False hides the macros but keeps them accessible from the console by typing their names manually, which the comment suggests is useful if you prefer to encapsulate them into your own macros.

So every visible knob exists to serve the printer's own constraints: RAM, SD card speed, and a web interface that will not surface macros it does not know about.

## The Python dependency set, and what zstandard is doing there

The requirements.txt file is short and specific, and each entry tells you something about how the plugin works.

GitPython is pinned at 3.1.41, matplotlib at 3.9.4, numpy at 2.2.2 for Python 3.10 and above, and zstandard at 0.23.0. The numpy pin is split by interpreter version, with numpy 2.0.2 for Python versions below 3.10 and 2.2.2 for 3.10 and above, which is a pattern you see when a dependency needs a specific build for an older interpreter.

matplotlib is the graphing library, and it is the heaviest of the three because the whole output of this plugin is plots. That also explains the dpi setting and the timeout setting, since a high resolution plot of a large spectral density array is real work, and a slow SD card makes reading the data back slow.

The GitPython dependency is the one that deserves a second look, because it is not part of the analysis. It suggests the plugin interacts with the git repository of the Klipper configuration, most likely to report which version of the configuration or the plugin itself is in use when it produces a result. For a diagnostic tool whose output you are going to attach to a bug report, knowing the exact version of the software that produced the graph is a reasonable thing to want.

zstandard is the compression library, and its presence is a strong hint about the data format. Standard compression of the.stdata files means the raw accelerometer measurements can be kept on an SD card without filling it, which is the same constraint that number_of_results_to_keep and keep_raw_data are working around. The.stdata extension is the plugin's own raw measurement format, and the docs directory holds the detail on how to use the macros or the CLI with it.

The pyproject.toml is where the packaging metadata sits. The distribution name is shake_n_tune, the version is dynamic, so the version number lives in the package source rather than in two places. The project requires Python 3.9 or newer, and the ruff configuration targets py39 with a line length of 120, which the comment explains as bringing the style in line with current technology.

The lint rule selection is worth a note for anyone contributing. The selected rules are E4, E7, E9, F and B, which is pycodestyle errors, pyflakes and bugbear, and the B rules are marked unfixable, which means the formatter is not allowed to rewrite the code that bugbear flags.

## Where the limits are, and what to check before you trust a result

The plugin's own documentation is the place to look for the boundaries, and the README points you at the detailed documentation in the docs directory for how to use the macros or the CLI. What the README itself already tells you is enough to frame the limits.

The first limit is hardware. Everything depends on a working accelerometer and a resonance_tester section. A machine without one cannot use this at all, and the accuracy of the whole result depends on how good that accelerometer is and how well it is mounted. The plugin analyses what the accelerometer reports, so it cannot be more accurate than the measurement.

The second is compute time. The timeout defaults to 600 seconds and the documentation says to raise it on slower hardware. A plugin that competes with Klipper for CPU and I/O on a low-end board is going to be limited by that board, and the measurements_chunk_size default of 2 exists specifically to avoid Klipper Timer Too Close errors on devices with little RAM. The bugbear of this tool is a small board, not an incorrect algorithm.

The third is that the plugin analyses and it does not decide. It gives you a filter recommendation and a set of graphs, and it will show you the resonance peaks it found. What to do about a resonance at a particular frequency depends on the mechanics of your machine, whether that is a stiffening mod, a different belt path or a change of mount. A plot is evidence, not a decision.

The fourth limit is about reproducing a problem. The keep_raw_data option exists because the processed graph is a summary and the raw .stdata is the evidence. If you want a maintainer to be able to help, you need the raw files attached, which is exactly what the configuration comment asks for when you report an issue on GitHub or Discord.

On maintenance, the repository is not archived, and the last push was on 2026-04-21. The three recent releases are v6.0.0 on 2026-01-16, v5.2.1 described as a hotfix on 2025-08-23, and v5.2.0 on 2025-08-23, so the v5.2.0 and v5.2.1 pair landed on the same day as a patch on a minor. A major version at 6.0.0 with a plugin that manages printer configuration is a reasonable place to be, and the gap between the newest release and the last push is a fact worth weighing if you are deciding whether to run this on a printer you depend on.

## Conclusion

Shake&Tune fits a Klipper user with an accelerometer who wants the measurement, the plots and the recommended input shaper filter in a single pass, and who is willing to install a plugin over SSH on the printer and read a long configuration block. It is the wrong tool if you have no accelerometer, since the resonance_tester section is a prerequisite, and the wrong tool if your printer's SD card is slow and you cannot spare the time each measurement takes. Before installing, read the documentation in the repository's docs directory, and if you intend to file a bug, enable keep_raw_data so the raw .stdata files are attached with the report, as the configuration comment asks.

## FAQ

### How do I install the Shake&Tune Klipper plugin?

Run wget -O - https://raw.githubusercontent.com/Frix-x/klippain-shaketune/main/install.sh | bash over SSH on your printer, then append a [shaketune] section to your printer.cfg and restart Klipper. You need a working accelerometer and a [resonance_tester] section defined first.

### Does Shake&Tune require the full Klippain setup?

No. The README states it can be installed on any Klipper machine and is not limited to those using the full Klippain. Klippain is the ecosystem it comes from, not a requirement.

### What does the measurements_chunk_size setting do in Shake&Tune?

It controls how many measurements are held in memory before a chunk is written to disk. The default of 2 is conservative to avoid Klipper Timer Too Close errors on devices with little RAM, and raising it to around 15 to 20 on a powerful computer reduces filesystem writes.

### Why should I enable keep_raw_data when reporting a Shake&Tune issue?

The configuration comment says to always attach the raw accelerometer .stdata files when reporting any issue on GitHub or Discord. The processed graphs are a summary, and the raw data is what a maintainer needs to diagnose the problem.

## Sources

- [Frix-x/klippain-shaketune on GitHub](https://github.com/Frix-x/klippain-shaketune)
- [Issues](https://github.com/Frix-x/klippain-shaketune/issues)
- [License: GPL-3.0](https://github.com/Frix-x/klippain-shaketune/blob/main/LICENSE)
- [README](https://github.com/Frix-x/klippain-shaketune/blob/main/README.md)
- [Releases](https://github.com/Frix-x/klippain-shaketune/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/frix-x-klippain-shaketune