結構な難題です、少々文が長くなります、多分意見がまとまらないテーマではないでしょうか、、
まず、前置きなのですが、MUSEは仕組みを少しだけ見た程度であまり詳しくありません。
これはご了承いただければと思います。
参考:
http://oto.chu.jp/txt/nowmml.htm
多分記述量の少なさと理解しやすさでは記載のとおり、総譜的な記述が良いと思います。
昔は自分もパート分けで考えてましたので、以下に理由や反省点も含め書き連ねてみました、
以下箇条書きになりますが申し訳ありません。
//------ ------ ------ ------ ------ ------
・まずサクラのストトン入力解説書に、トラック(パート)分けとして記述されている。
・リズムトラックがMMLの場合かなり特殊で例えば、$b{n36,}、Rhythm{Sub{...}...}、と
書き込まなければならないため、許される記述が把握しずらい面がある。
・なにより見た目がかっこいいことを重視するMMLや、記述的に面白いストトンを書き込むなど、
先人によってかなり違いがあるため、決まった入力法が定まっていない。
・また、違いを許容する多用な入力法があり、Play(,{ccc},{ggg})のように、
トラックコマンドを使わずとも書き込むこともできる。
・リアルタイムなミディ方面から来た場合ドンカマを組んで伴奏、メロ、リズム隊と楽器を加えるため、
トラック分けのほうが工程として慣れている。
・入力支援の ここから演奏、PlayFrom(time)、?、などで、どのトラックであっても簡単に、
聞きたい場所から演奏開始できるため、構成をまとめなくても入力できてしまう。
・新しい入力法を試すより確実な方法を選択しがちのため。
要因として、MMLの構文エラーの恐怖。
点が抜けただけで暴走するので、この発見にたいへん時間がかかる経験が誰しもある、
別の要因として、各トラックのタイムカウンタが合わないなどの入力不安。
TR切換えが裏で何を行っているか、分かりずらい、(TRはタイム値の確保、音色の確保などを
TRごとに独立して行っている)
タイム(Tick)の概念がとても理解しずらい、(サクラの場合、r,^,a-g,nコマンドの時だけ時間が送られる)
・MMLの歴史の影響も若干あるかもしれません。
自分はPMD(FM音源用MML)が少し読めるぐらいなので、正直おこがましいと思う方もいるかもしれませんが、
特定トラック=モノフォニック音源という制約のうえで少しでもデータを抑えるため、
この音源に対するMML記述を減らしたい合理的解決として導き出されたのが、
TR分けごとにMMLだったのではないかと思っています。
それとこれは憶測の域を出ませんが、PMDの場合は行をコメントアウトするのみで良いので
MMLの構文エラーが出た時の発見がしやすかったのかなと思います。
//------ ------ ------ ------ ------ ------
総括としては、エラーの発見しやすく入力を少なくしたい、
すでにベテランの域なのであれば、TR分けが間違いなく速いです。
ただしご指摘の通り、幾分手がかかりますが時間軸に沿った入力のほうが
恐らく管理がしやすく、再利用も簡単だと思います。
最後になりましたが、これを生かした時間軸に合わせたシンプルな凡例を載せました。
// Header
Include(gs.h) ResetGS r1 TrackSync
TR 1 @6 o4 l8
TR 2 @81,8 o6
TR 10 l8 TrackKey=-1 o3
// PartA 1小節
TR 10 TrackSync // 全TRのタイムカウンタを、TR10のタイムへ合わせる
TR 1'ce'^^r 'cg'^^'ce'
TR 2 l16 d^^g d^^c // 後にTrackSyncするので、はみ出さない限り不足ぶんの帳尻は気にしなくても良い
TR 10 cgfc cgfc
// PartB 1小節
TR 10 TrackSync
//? // ?ひとつでPartBから再生できる
TR 1 'df'^^r 'da'^^'df'
TR 2 r-8 gab`c ragf ^e // PartBより8分音符早める
TR 10 cgfc cgfb