更新待办事项

README.md

@@ -119,7 +119,11 @@
 
 如果需要与开发组进行交流，欢迎加入我们的[开发闲聊 Q 群](https://jq.qq.com/?_wv=1027&k=hpeRxrYr)。
 
-亦可以联系我们[睿乐组织官方邮箱](mailto:TriM-Organization@hotmail.com)，取得进一步联系！
+亦可以联系我们组织的[邮箱](mailto:TriM-Organization@hotmail.com)！
+
+## 待办 ⏰
+
+当前未完成的任务和一些需要讨论的内容都收集在了[任务清单](./TO-DO.md)里，当然你也可以提[工单请求](https://gitee.com/TriM-Organization/Musicreater/issues/new)来进行讨论。
 
 ---
 

TO-DO.md

@@ -1,49 +1,61 @@
 # 任务清单
 
 ## 待办事项
--	乐曲文件格式设计
+-	- [ ] 乐曲文件格式设计
 	目前想到的是：
 	1.	使用 `.MCT` 作为项目文件的后缀，然后考虑一下格式是否和之前的 MusicSequence 兼容，如果兼容的话可以照旧用 `.MSQ`，如不的话，可以试试想一个新的后缀名作为数据文件后缀
 	2.	要求数据文件支持完全流式读入
 
--	[] 音轨静音处理
+-	- [ ] 音轨静音处理
 	当前没有处理
 
--	[] 优化音轨的存储方式
+-	- [ ] 优化音轨的存储方式
 	当前是用列表，且每一次变动元素都要重新排序，这样消耗太大了，需要优化，改用最小堆形式（heapq）
 
 -	移植 v2 功能到内置插件
 	目前 v2 的功能有很多，都要移植到 v3。
-	1.	[x] 导入 Midi 文件到全曲
+	1.	- [x] 导入 Midi 文件到全曲
-	2.	[] 导入 Midi 文件到指定轨道
+	2.	- [ ] 导入 Midi 文件到指定轨道
-	3.	[x] 导出到延迟播放器的结构文件（MCSTRUCTURE、BDX）
+	3.	- [x] 导出到延迟播放器的结构文件（MCSTRUCTURE、BDX）
-	4.	[] 导出到延迟播放器的附加包
+	4.	- [ ] 导出到延迟播放器的附加包
-	5.	[] 导出到积分板播放器的以上两种形式
+	5.	- [ ] 导出到积分板播放器的_以上两种形式_（结构文件和附加包）
-	6.	[] 导出到中继器播放器的以上两种形式
+	6.	- [ ] 导出到中继器播放器的以上两种形式
-	7.	[] 在 WebSocket 播放器中播放
+	7.	- [ ] 在 WebSocket 播放器中播放
-	8.	[] 导出到支持神羽资源包的以上 7 种形式
+	8.	- [ ] 导出到支持神羽资源包的以上 7 种形式
-	9.	[] 对于 Midi 歌词的实验性功能
+	9.	- [ ] 对于 Midi 歌词的实验性功能
-	10.	[] 对于 Java 版本适配的实验性功能
+	10.	- [ ] 对于 Java 版本适配的实验性功能
-	11.	[] 对于听感优化的实验性功能（插值、偏移）
+	11.	- [ ] 对于听感优化的实验性功能（插值、偏移）
 
--	[] 测试参数曲线的功能
+-	- [ ] 测试参数曲线的功能
+	是的，我们现在还没有测试参数曲线的功能。
 
--	[] 支持导出音符盒构成的音乐
+-	- 制作更多新的内置或附加插件
+	1.	- [ ] 支持导出音符盒构成的音乐
+	2.	- [ ] 支持导出成 schematic 结构
+	3.	- [ ] 导出到以瀑布流为主要形式的各种播放器
+	3.	- [x] 支持瀑布流式样的动画内容导出（详见[音·视](https://gitee.com/TriM-Organization/MineMusicVisualizer)）
+	4.	- [ ] 在中继器播放器中，支持将指定玩家移动到对应播放位置
+	5.	- [x] 支持将音乐渲染成音频文件（详见[音·预](https://gitee.com/ElapsingDreams/MusicPreview)）
+	6.	- [ ] 音符可视化的拓展，该内容可以考虑作为音·预以及音·视的子插件
+	7.	- [ ] 支持导入 Everyone Piano 的曲谱文件（.eop）
+	8.	- [ ] 支持导入 Musescore 的通用曲谱文件，即 musicXML（.mscz、.mscx）
+	9.	- [ ] 支持导入 JPword 曲谱文件（.jpd）
+	10.	- [ ] 支持识别曲谱图片以导入
+	11. - [ ] 支持识别地图或者结构中利用中继器进行播放的音乐并导入
 
--	[] 支持导出成 schematic 结构
 
 ## 讨论
 
-1.	[x]	是否应该在插件注册表 PluginRegistry 中采用 `Dict[插件名, 插件对象]` 的形式存储插件？
+1.	- [x] 是否应该在插件注册表 PluginRegistry 中采用 `Dict[插件名, 插件对象]` 的形式存储插件？
 	当前不采用这种方式是认为可以兼容一些极端场景下用户将一堆同名插件放在一起的情况。但是就算是插件放在一起，我们也可以有选择地读入注册表，比如依照版本号只读取最高版本的插件，并不需要全部存储在插件注册表中。所以其实用字典来存储是有利的？吗？
 	
 	**当前已解决**
 
 	引入了插件惟一识别码之后当然是采用 `Dict[插件唯一识别码, 插件对象]` 来存储插件了~之前插件名称的内容是我想得太浅了，我写完所有代码之后才想到插件名称是中文还带空格的任意字符串……
 
-2.	[] 服务插件到底该怎么写？总不能留着一个 PluginType.SERVICE 的插件一直空在那里吧……
+2.	- [ ] 服务插件到底该怎么写？总不能留着一个 PluginType.SERVICE 的插件一直空在那里吧……
 
-3.	[x] 插件依赖性的优化。目前没有处理各个插件依赖关系的问题，如果插件之间彼此依赖要怎么做？
+3.	- [x] 插件依赖性的优化。目前没有处理各个插件依赖关系的问题，如果插件之间彼此依赖要怎么做？
 	我的想法是，这个依赖的处理由调用端来完成。比如我们的 伶伦工作站 是以 音·创 为核心的一个可视化数字音频工作站。
 	那么应该由伶伦来处理依赖关系并加载之。
 

examples/exp_dataexport_plugin.py

@@ -78,7 +78,7 @@ class ExampleExportMusicPlugin(MusicOutputPluginBase):
         for cfg in config:
             yield self.something_data_convert(cfg)
 
-    # 插件可选地定义 dump 方法，从文件导入数据。下面展示的是不定义 load 方法时候的实现方式
+    # 插件可选地定义 dump 方法，导出音乐数据到文件。下面展示的是，在不定义 dump 方法时候的，默认的实现方式
     def dump(
         self, data: SingleMusic, file_path: Path, config: ExampleExportConfig | None
     ):