我对键音包功能的架构设计上, 有了一些新想法:

[LuSrackhall]

我对键音包功能的架构设计上, 有了一些新想法:

主要是因为, 目前为止(11月10)号的键音包架构, 以及现阶段实现, 不能让某些场景更方便, 如下所述:

• 如果用户上传的声音源文件本身, 就是短暂到可以直接使用的声音, 那么我们似乎没有必要强制对其进行进一步的裁剪定义(虽然裁剪定义中, 也支持使用整个音频的长度作为默认值, 但对此种情况来说这个步骤还是有些多此一举了)。为此, 应该支持在 按键音的制作时 或是 配置 全局/具体按键绑定 时, 直接选用"声音源文件"来使用, 而不是仅能选择 "裁剪定义的声音"。
• 对于按键音的制作, 不管是按下还是抬起的声音列表中, 应该支持三种类型的选择, 三种类型分别是: "直接选用声音源文件"、"选用裁剪定义好的声音(目前的架构, 仅支持此项选择)"、"选用已定义好的按键音(如作此选用, 不用担心按下抬起声音的区分问题, 软件会自动识别当前是按下或抬起声音, 以匹配已有按键音中的对应列表)"

[LuSrackhall]

适配新架构下, 编辑已有声音 对话框 中的业务逻辑, 目前适配进度-> 1.利用绑定uuid解决潜在的引用变更问题;2.解决了展示label时, 因类型不匹配造成的报错问题; 8662828

[LuSrackhall]

至此, 目前已按照当前想法重新组织了基础架构。 后续, 只需继续按此架构实现后续的 配置 全局/具体按键 绑定的 逻辑。