MusicXML 和打击乐符号

上周末我注意到我在 StaffPad 和 Dorico 之间来回切换时遇到了许多挫折，因为两者之间的音乐 XML 传递令人沮丧，尤其是在打击乐方面——而且，剧透，我的管弦乐作品充分利用了打击乐器！ 1 虽然我仍然有点悬而未决，我最终会选择其中一个作为主要工具——最近来自 Dorico 的消息使这成为一个更有趣的考虑！ 2 - 但与此同时，我认为深入研究两者的不同之处和原因会很有趣。在这篇文章中，我将深入探讨这些应用程序在表示单个打击乐器的方式上的主要差异：木块。我选择 Wood Blocks 是因为它们比低音鼓或军鼓之类的东西更复杂：它们被归类为无音高的打击乐，因为它们没有确定的音高，但它们在整个块上有不同的音高。他们总是表现为某种多线工作人员。然而，不同的工具呈现不同的员工！它们不是像架子鼓乐谱那样将完全不同的打击乐器组合在一起，但是这些块也有不同的元素，可以以不同于钢琴或钟琴的方式进行打击。虽然 Dorico 版本更符合标准习语，但 StaffPad 版本并没有错：我已经看到 Wood Blocks 在世界上出版的音乐中完全以这种方式表示。不过，这里有一个主题：StaffPad 为这样的事情所做的通常很好，但 Dorico 所做的通常更接近正确”，因为这种事情存在于乐谱中。这组差异意味着查看木块将向我们展示我们需要了解的有关程序对打击乐表示的潜在差异的大部分信息。我们可以安全地从我们将在下面看到的进行概括！

这给了我们关于这两个程序如何以不同方式对乐器进行建模的第一个提示：StaffPad 在某些方面将其视为无音高的乐器（注意五线谱开头的两根粗小节），但使用的是倾斜乐器风格的五线谱来代表它。 Dorico 正在做一些完全不同的事情，每个木块只有一条线——就好像它把每个木块代表为一个不同的乐器，但组合在一起形成一个单一的视觉表现。事实证明，这种视觉差异（在这里很明显，因为它不一定在我们可能看过的其他更简单的打击乐器中）正是引擎盖下发生的事情。更重要的是，我实际上在这里作弊使这些看起来比平时更相似。默认情况下，Dorico 实际上以单独的块命名来呈现这些：我不遗余力地创建了一个组，以使记谱法尽可能接近 StaffPad 的记谱法，以突出显示五线谱的差异，但使用默认的乐器命名考虑到它变得更加清晰：Dorico 将每个块视为无音高线上的一个独特项目，而 StaffPad 将它们视为一个单一的乐器，将无音高的块映射到有音高的五线谱上，并相应地呈现它们。这里有几个兴趣点。一是如何定义工具本身。两个程序都遵循此处的 Music XML 规范，但它们代表乐器的方式却大不相同——尽管考虑到我们在上面看到的情况，这并不奇怪！ Wood Blocks Wood Block 1 Wood Block 2 Wood Block 3 Wood Block 4 Wood Block 5 StaffPad 和 Dorico 都把这个乐器当作一个乐谱部件，实际上它恰好有一个匹配的部件 ID 在 StaffPad 中，木块被表示作为该顶级乐谱部分中的单个乐谱工具。在 Dorico 中，每个木块都是乐谱部分中的一个单独的乐谱乐器和乐器名称。

结果是我上周发现的：来自 StaffPad 的打击乐器的不同线条最终映射到 Dorico 中的多个不同乐器。当我们深入到 Music XML 文件的 <part> 部分时，这会继续下去。 <part> 代表乐谱中的每个音乐部分，并保存属于该部分的所有小节。如果我们看看这两个程序如何表示各个部分，我们就会明白为什么很难从一个程序转换到另一个程序。 192 0 major 4 4 1 percussion 5 0 0 0 <!-- ... <note>s... --> 首先要注意 4 是在人员详细信息定义中。这是一个显示快速比较的表格：两者都对谱号使用打击乐（尽管 Dorico 在这里也明确指定了谱号编号属性），并将这部分的谱表设置为 1，正如我们所期望的：除了钢琴、竖琴、或类似的将是单五线谱乐器。除此之外，两者大相径庭。 StaffPad 指定人员行（在人员详细信息容器内），但是虽然它可以选择使用行详细信息元素来完全按照 Dorico 的方式来表示这一点……但它并没有那样做。相反，它只是指定有五个员工线并继续前进。同时，Dorico 完全跳过了这一点，因为它已经对块的表示进行了编码：在顶部的部件列表中。同样，Dorico 根本没有指定移调，因为它与此乐器无关。 5 当我们查看单个音符时，这种模式会继续存在。让我们看看每个程序如何表示第一个音符，最低的木块。 （其余的音符基本相同，只是敲击的木块有所不同。）这次 Dorico 有更多的信息，但这是因为它将木块编码为真正的无音调并将它们表示为单独的乐器，如我们在零件清单中看到了。 StaffPad 将第一个音符表示为高音音符：G4”。 Dorico 将它表示为一个无音高的音符，它出现在 E4”的特定显示音符和八度音程中。在这种情况下，虽然 StaffPad 的表示在已发布的音乐中是未知的，但 Dorico 的绝对是更正确的表示。您还可以看到，作为选择将块表示为单个乐器的结果，Dorico 需要使用 id 属性指定乐器，并指定设置音符的乐谱编号。对于 StaffPad 来说，后面的那些位是免费的，因为它选择使用音符的音高表示，但代价是表示具有技术上不正确的语义。

值得在这里停下来注意，程序可以选择 Dorico 表示的替代方案，这也是正确的。例如，您可以将 line-detail 元素用于五线谱内的不同线条，并采用与 Dorico 一样的无音高音符和显示步长和显示八度音程的方法。 （关键不在于 Dorico 做对了——虽然我认为它做对了——而是 StaffPad 做的有点不正确。）但即便如此：格式足够灵活，无论如何互操作都会很困难。对我来说，如果 StaffPad 切换到我在此处描述的编码，Dorico 的导入会更好地工作，这对我来说并不明显。这只是一个难题！如果您很好奇并想自己深入研究，我已经上传了本讨论中使用的两个音乐 XML 文件；随意看一看：当我们走到最后时，您可能想知道这一切的意义是什么。嗯，一方面，我希望这对我以外的其他人有帮助，可以准确了解这种音乐交流格式中发生的事情。了解这些事情的复杂性可以让人们更容易同情软件开发人员：他们的工作非常辛苦！ 6 另一方面，我开始深入研究这个问题，看看编写一个小工具将 StaffPad 的输出转换成 Dorico 能够理解的东西是多么困难。我想答案是：不太难！我需要检查每种打击乐器并确保它正确地转换它，但这是我过去从其他类型的 XML 混合中知道如何做的事情。 7 虽然我不知道我会做那件事，但我现在很清楚这需要什么。可以肯定的是，这将是一些不平凡的工作；但取决于我正在进行的工作流程是什么样的，它最终对我来说可能是值得的。如果确实如此并且我构建了该工具，我当然会在此处以及在相关软件程序的各种论坛中分享它。 （虽然没有承诺，但真的！）大多数读者可能不知道的一件事：从前在高中时，我在管乐合奏中演奏打击乐。我很喜欢它，我学到了很多东西！ ↩︎ POWAHHHRR，无限的 POWAAHHHHRRRR — 错误，抱歉，我指的是 iPad 版 Dorico 上的无限部分。 ↩︎

了解 Dorico 的人可能有兴趣知道，无论木块是否在打击乐器组中，这都是正确的。 ↩︎ 您可能还会注意到 <divisions>、<key> 和 <time> 在处理方式上的不同。这很有趣，我强烈怀疑它指出了两个程序如何概念化/建模音乐的其他根深蒂固的差异，但对我们今天的目的来说并不重要。 ↩︎ 这几乎肯定不是一个有意识地根据每个乐器选择要做什么的情况。而是：程序指定如何为给定的数据桶导出 XML，然后它会自动进行。所以，最有可能的是，StaffPad 对每个乐器都有一个 transpotioin 的表示，即使它被默认了，就像这里，没有什么有趣的，继续前进；而 Dorico 可能根本没有这样的乐器。 XML 导出仅反映该内部表示。 ↩︎ 我对此有既得利益，即使我（目前？）不使用乐谱软件。 ↩︎ 事实证明，当我建立 HolyBible.com 时，使用 OSIS 代表的 KJV 圣经，这十年的大部分时间教会了我很多。 ↩︎