Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

MIDI controller settings are silently lost on the next launch

未关闭
  • 哪里不对？
#3,883 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 5 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
70/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
cpp
领域
api, desktop

调研方向

从 src/settings.cpp 中第 636 行和第 655 行附近的范围检查开始，然后检查 src/clientrpc.cpp 第 421 行附近的代码。在重启后分别复现命令行和 JSON-RPC 的持久化流程。完成标准是：最大为 128 的有效 MIDI 计数在重新加载后仍然保留，并且 setMidiSettings 不再接受读取器会丢弃的值。

由索引模型根据 Issue 内容生成。

描述

AI

🤖 AI: MIDI controller settings do not survive a restart. Two independent defects produce the same symptom: the ini reader's range checks reject values that then reset to 0, and the JSON-RPC setter accepts values it never validates. All measured on main @ 8b667a3a, Qt 5.15.3, x86-64, QT_QPA_PLATFORM=offscreen.

1. --ctrlmidich count of 128 is rejected on reload (ini range check off by one)

CSettings::ReadFromFile range-checks nine MIDI keys against one shared 0..127 (src/settings.cpp:655). Four of those keys are counts rather than CC numbers, and both documented --ctrlmidich syntaxes legitimately produce 128:

  • legacy 1;0 sets iMidiFaderCount = qMin ( MAX_NUM_CHANNELS, 128 - iOffset ) = 128 (src/settings.cpp:285)
  • named 1;f0*128 sets iNum = qMin ( iNum, MAX_NUM_CHANNELS ) then qMin ( iNum, 128 - iFirst ) = 128 (src/settings.cpp:332)

128 is then written to the ini, and GetNumericIniSet's upper bound is inclusive (src/settings.cpp:144), so the stored value fails the check on read, the member keeps its default, and the count lands at 0. One launch with the flag to write the ini, one launch without it to read back:

key after --ctrlmidich "1;<t>0*128" after the next launch
midifadercount 128 0
midipancount 128 0
midisolocount 128 0
midimutecount 128 0

Control, identical procedure with *127 instead of *128: all four read back 127. A count of 0 maps no controllers, so a full-width MIDI map works for exactly one session and is gone from the next one, with nothing logged. Fix: split the shared range so offsets stay 0..127 and the four counts accept 0..128.

2. jamulusclient/setMidiSettings has no range validation, so values persist and then vanish on reload

The JSON-RPC setter writes every field straight to settings with no bounds check (src/clientrpc.cpp:421). Out-of-range values are accepted (the call returns {"result":"ok"}), saved to the ini on quit, and silently dropped by the reader's range checks on the next launch. One client driven over the JSON-RPC socket, quit, relaunched on the same ini:

field (valid range) set via RPC read back, same session in the ini after relaunch
midiChannel (0..16) 99 99 <midichannel>99</…> 0
midiFaderOffset (0..127) 5000 5000 <midifaderoffset>5000</…> 0
midiFaderCount (0..127) 200 200 <midifadercount>200</…> 0

midiChannel is checked at src/settings.cpp:636, the offsets and counts at src/settings.cpp:655, so all three fail on load and reset to the default 0 — the same silent-loss mechanism as case 1, reached through the RPC instead of the command line. Fix: validate the fields in setMidiSettings (reject or clamp) so a value the API accepts is one the reader will keep.

🤖 This message was written by AI and reviewed by @mcfnord.

主要语言
C
星标
1.1k
派生
248
平均合并
7 天 4 小时
30 天内合并 PR
5

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

jamulussoftware/jamulus 的其他 Issue

查看 jamulussoftware/jamulus 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。