At high MIDI update rates, the host application can crash while CCTrack's
control changes drive plugin parameters. This was seen with one host and
one plugin, so the scope is unknown — it is recorded here rather than in
the docs, because we cannot generalise from a single combination.
Observed
- Setup: REAPER 7.79 (Linux, PipeWire), IEM SceneRotator 0.4.7 (VST3)
reading CCTrack through the plugin's own MIDI input, output_mode=cc14,
firmware v0.1.0.
midi_rate_hz=200: REAPER aborts (SIGABRT), repeatedly, within minutes.
midi_rate_hz=100 (the firmware default): no crash in testing.
- A pre-release firmware with a slower, uneven sample stream (~215 Hz instead
of 400 Hz) crashed noticeably sooner at 200 Hz.
What the core dumps show
All dumps (coredumpctl info <pid>) show two threads inside the plugin's
parameter code at the same moment:
- audio thread:
processBlock → setValueNotifyingHost → updateQuaternions
→ juce::AudioProcessorValueTreeState::ParameterAdapter::parameterValueChanged
- host main thread:
setParamNormalized → SceneRotator::parameterChanged →
updateEuler → the same ParameterAdapter code → abort()
Every CC is a parameter change that the plugin reports to the host, which the
host then echoes back; the Euler ↔ quaternion cross-updates run concurrently.
A higher MIDI rate means more parameter updates, and more opportunities for
the two paths to overlap.
Assessment
- The MIDI CCTrack sends is valid; the rate and timing only change how often
the overlap occurs.
- Whether this is specific to this plugin, to this host, to VST3 parameter
echo, or a more general pattern is untested. Only one plugin and one
host have been tried, on Linux.
Mitigations for users
- Keep
midi_rate_hz at the default 100, or lower it
(tools/cctrack-cmd.py <port> set_config midi_rate_hz=50; takes effect
immediately).
- Use the CDC quaternion stream (
python/) where possible — it is unaffected.
Open
- Test more hosts/plugins and other plugin formats, on Linux, macOS and Windows.
- If the pattern holds up, report it upstream with the stack traces.
At high MIDI update rates, the host application can crash while CCTrack's
control changes drive plugin parameters. This was seen with one host and
one plugin, so the scope is unknown — it is recorded here rather than in
the docs, because we cannot generalise from a single combination.
Observed
reading CCTrack through the plugin's own MIDI input,
output_mode=cc14,firmware v0.1.0.
midi_rate_hz=200: REAPER aborts (SIGABRT), repeatedly, within minutes.midi_rate_hz=100(the firmware default): no crash in testing.of 400 Hz) crashed noticeably sooner at 200 Hz.
What the core dumps show
All dumps (
coredumpctl info <pid>) show two threads inside the plugin'sparameter code at the same moment:
processBlock→setValueNotifyingHost→updateQuaternions→
juce::AudioProcessorValueTreeState::ParameterAdapter::parameterValueChangedsetParamNormalized→SceneRotator::parameterChanged→updateEuler→ the sameParameterAdaptercode →abort()Every CC is a parameter change that the plugin reports to the host, which the
host then echoes back; the Euler ↔ quaternion cross-updates run concurrently.
A higher MIDI rate means more parameter updates, and more opportunities for
the two paths to overlap.
Assessment
the overlap occurs.
echo, or a more general pattern is untested. Only one plugin and one
host have been tried, on Linux.
Mitigations for users
midi_rate_hzat the default100, or lower it(
tools/cctrack-cmd.py <port> set_config midi_rate_hz=50; takes effectimmediately).
python/) where possible — it is unaffected.Open