Link: SynapticStrings/QyEditor: Lightweight synthesizer interface.

想法来源

关于与 DiffSinger

确定想要自己开发的 trigger 是看到 DiffSinger 交流群有一位视障的朋友关于 DiffSinger 的无障碍支持提出了意见，我思维风暴了一下，自己本身确实有很多想法，想要构建出一个原型验证可行性，确定了实时 WebUI 的方案（致敬传奇歌声合成软件大市唱 和其成名曲《摘苹果》）。

再加上自己想要实现能够在 Intel 显卡上运行用在 OpenUTAU 的 DiffSinger 声库¹。但是不会 C♯ ，所以想要尝试自己踩坑。

又因为之前配置能够在 I 卡运行 PyTorch 的 Python 环境的糟糕经历，加之 Python 拉跨的速度与并发性能，果断放弃了使用 Python 来开发。

查看资料发现 Elixir 生态存在运行 ONNX 的库（elixir-nx/ortex），发现其是 pykeio/ort 的 Elixir 包装，后者可以通过 Execution Provider 在 I 卡在运行，故确定了开发计划。

大致如下：

• [DiffSinger] 手动在性能相对优越的设备编写脚本并且执行推理，确定能够通过 Ortex 在 Elixir 生态使用 DiffSinger
• [Ortex] 尝试自己搭建能够通过 OpenVINO EP 在 Intel GPU 执行推理任务，修改 Ortex 的源码使其可被调用，提交或是自己维护相关分支
• [QyEditor] 实现编辑器本体
  • 贝塞尔曲线编辑参数
  • 对声库内模型的查找以及组织来确定模型之间的依赖关系，实现更强的兼容
  • 分「演奏」与「调教」等环境，不同环境的设计思路和以往的应用完全不同，并且考虑无障碍支持

很轻巧是吧？

但是在第一步就出现问题了。

在此之前一句话讲一下 DiffSinger ：利用扩散模型来生成歌声的模型，其属于参数较多运算复杂的模型。

（抱歉，写到这里发现自己缺乏很多相关的基础知识以至于无法很清晰地描述自己的问题以及困境）

ComfyUI-like 与流程操作

既然选了 Elixir ，那么不加点什么符合这个语言调性的特征就不大好。

我记得某次 José Valim 被问到有关 Elixir 的应用场景时说到，只要和数据流有关的情景，理论上都可以选用 Elixir 。

在 AI 绘图爆火的 23 年年初，我就想过要构建一个节点操作的方法。

但那个时候对 FP 一窍不通，故选择 Python ，但是在尝试哼哧哼哧写了很久的 fbp 组件还没写完，ComfyUI 就诞生了（我假定你们知道这是什么）。

也因此我自己写的 UI 就放弃了。

但是这个想法一直存在。

本体

目前负责调度的内核已经完成，因其泛用性，改成了 Orchid 。

QyXxx 则更专注。

困境

ONNX Segment fault

参见 Elixir crash quitely when loading ONNX model · Issue #42 · elixir-nx/ortex 。

tough academic issue

庞大的工作量

leverage AI, plz.

---

1. OpenUTAU DiffSinger 声库实质上是 ONNX 模型↩︎