Follow-up from #112. The Strings modal was constrained during review to shapes the current tuning model can represent, because the model only supports a fixed set of extended shapes (guitar 6→8 low, bass 4→6). The original PR's 'add at either end / 4-string guitar / 5-string banjo' framing produces shapes the model can't represent, so _stringCountFor silently re-snaps the count and relabels note-string indices → chart corruption.
Delivered in #112 (safe subset): direct per-string tuning entry + add/remove at the model-supported ends only.
Not delivered (needs this issue): arbitrary either-end add/remove, 4-string guitar, 5-string banjo. To do it correctly, store per-string open-pitch/label explicitly (not derived from a fixed shape table), which touches the save/wire format and _openMidiForArr/laneLabels/_stringCountFor. Requires a data-model + format change, so it's out of scope for a review pass.
Follow-up from #112. The Strings modal was constrained during review to shapes the current tuning model can represent, because the model only supports a fixed set of extended shapes (guitar 6→8 low, bass 4→6). The original PR's 'add at either end / 4-string guitar / 5-string banjo' framing produces shapes the model can't represent, so
_stringCountForsilently re-snaps the count and relabels note-string indices → chart corruption.Delivered in #112 (safe subset): direct per-string tuning entry + add/remove at the model-supported ends only.
Not delivered (needs this issue): arbitrary either-end add/remove, 4-string guitar, 5-string banjo. To do it correctly, store per-string open-pitch/label explicitly (not derived from a fixed shape table), which touches the save/wire format and
_openMidiForArr/laneLabels/_stringCountFor. Requires a data-model + format change, so it's out of scope for a review pass.