# 任务清单

## 待办事项
-	乐曲文件格式设计
	目前想到的是：
	1.	使用 `.MCT` 作为项目文件的后缀，然后考虑一下格式是否和之前的 MusicSequence 兼容，如果兼容的话可以照旧用 `.MSQ`，如不的话，可以试试想一个新的后缀名作为数据文件后缀
	2.	要求数据文件支持完全流式读入

-	音轨静音处理
	当前没有处理

-	优化音轨的存储方式
	当前是用列表，且每一次变动元素都要重新排序，这样消耗太大了，需要优化，改用最小堆形式（heapq）

-	移植 v2 功能到内置插件
	目前 v2 的功能有很多，都要移植到 v3。
	1.	导入 Midi 文件到全曲
	2.	导入 Midi 文件到指定轨道
	3.	导出到延迟播放器的结构文件（MCSTRUCTURE、BDX）
	4.	导出到延迟播放器的附加包
	5.	导出到积分板播放器的以上两种形式
	6.	导出到中继器播放器的以上两种形式
	7.	在 WebSocket 播放器中播放
	8.	导出到支持神羽资源包的以上 7 种形式
	9.	对于 Midi 歌词的实验性功能
	10.	对于 Java 版本适配的实验性功能
	11.	对于听感优化的实验性功能（插值、偏移）

-	测试参数曲线的功能

-	支持导出音符盒构成的音乐

-	支持导出成 schematic 结构

## 讨论

1.	[x]	是否应该在插件注册表 PluginRegistry 中采用 `Dict[插件名, 插件对象]` 的形式存储插件？
	当前不采用这种方式是认为可以兼容一些极端场景下用户将一堆同名插件放在一起的情况。但是就算是插件放在一起，我们也可以有选择地读入注册表，比如依照版本号只读取最高版本的插件，并不需要全部存储在插件注册表中。所以其实用字典来存储是有利的？吗？
	
	**当前已解决**

	引入了插件惟一识别码之后当然是采用 `Dict[插件唯一识别码, 插件对象]` 来存储插件了~之前插件名称的内容是我想得太浅了，我写完所有代码之后才想到插件名称是中文还带空格的任意字符串……

2.	服务插件到底该怎么写？总不能留着一个 PluginType.SERVICE 的插件一直空在那里吧……

3.	插件依赖性的优化。目前没有处理各个插件依赖关系的问题，如果插件之间彼此依赖要怎么做？
	我的想法是，这个依赖的处理由调用端来完成。比如我们的 伶伦工作站 是以 音·创 为核心的一个可视化数字音频工作站。
	那么应该由伶伦来处理依赖关系并加载之。