Tracktion中为何MIDI音符修改时不调用Edit::markAsChanged()？

• 数据分层与职责划分
  Tracktion的对象架构采用分层设计：Edit是顶层项目容器，Track、Clip属于中层对象，MIDI音符这类细节数据则是Clip内部的子数据（存储在MidiClip的MidiSequence或MidiList结构中）。添加轨道、移动音频片段这类操作直接作用于Edit或Track层级，代码逻辑里会显式调用Edit::markAsChanged()标记整个项目状态变更；但修改MIDI音符时，操作仅作用于Clip内部的MIDI数据结构，这一层级的修改默认不会向上冒泡触发Edit的变更标记。

• 性能优化考量
  MIDI音符修改属于高频操作（比如连续绘制、拖拽调整音符），如果每次修改都触发Edit::markAsChanged()，会频繁触发项目保存提示、全局状态同步等开销较大的操作，拖慢编辑器响应速度。Tracktion的设计选择仅在Clip整体属性（如位置、长度、启用状态）变更时触发Edit层级的标记，内部MIDI内容的修改仅更新局部界面和数据，避免不必要的全局状态变更。

• Undo/Redo机制的关联差异
  添加轨道、移动片段这类操作会被封装为Edit层级的Undo动作，动作执行时会自动调用markAsChanged()；而MIDI音符修改的Undo动作通常属于Clip内部层级，默认不关联Edit的状态变更标记。如果需要让MIDI修改触发Edit变更，需在MIDI编辑的Undo动作完成后，手动调用clip->getEdit()->markAsChanged()。

内容的提问来源于stack exchange，提问作者groszobquivousemmerde