fourthline / mmlTools

MabiIcco - マビノギ用MMLエディタ (MML editor for Mabinogi)
https://fourthline.jp/mabiicco/
51 stars 19 forks source link

MML書き出しに影響する設定をMMIファイルに記録する機能 #111

Open Colimoceise opened 3 months ago

Colimoceise commented 3 months ago

MMLを誰かと共有する際、MabiIcco形式のMMIファイルを送るだけでは、お互いのMabiIccoの設定(とMabiIccoのバージョン)の違いによって、クリップボードに書き出すMMLの中身が変わることになります。 だから、完全に等しいMMLを共有しようとすると、MMIファイルではなくて最適化済みのMMLそのものをやりとりする、あるいは、作譜者が相手にMabiIccoの設定などを教えておく必要があります。

設定によるMMLの出力の違いが問題になる場面は、ほとんどないと思いますけれど、たとえばフリースタイルジャムで演奏するとき、テンポ指定が和音パートにあると、打楽器だけそのテンポが反映されず、ずれてしまいます。 「和音にテンポ出力を許可する」の設定の差だけで、演奏結果が変わるということになります。かなり特殊なケースですけれど。

そこで、MMIファイルを開いたときに設定も再現されれば、そういう事故も減りそうですけれど、知らないうちに設定が上書きされるというのは不親切でしょうから、 「MMIファイルを保存した時点での、(MML書き出しに関係する)設定項目の状態、MabiIccoのバージョンを、MMIファイルにも記録しておき、あとから確認できるようにする機能」 があるといいと思います。 自分自身がつくったMMIファイルであっても、作成時のバージョンの情報などがMabiIccoで表示できるなら、きっと便利なことと思います。 とはいえ、このようなこまかいことを気にすべき場面がどれくらいあるだろうか、とも思うし、最低限、MMIファイルをテキストエディタでひらいて値が確認できるだけの、隠し機能みたいな扱いでもよいです。

御検討していただければ幸いです。

Lisedrika commented 3 months ago

和音の方でもテンポを変更できるのは、もともとMMLの基本仕様です。 3MLEだけでなく、キーボードで直接入力しても実現可能です。 厳密に言えば、フリースタイルがこれを反映していないわけです。

ただし、これをそのまま放置することはできないので、MMLを出力する際にフリースタイル専用に出力するオプション(チェックボックス)があれば解決が可能だと思います。

最新バージョンで制作された楽譜を昔のバージョンがサポートできない部分は、どんな番組でも当然のことではないかと思います。 つまり、「アップデートを怠った側の責任じゃない?」という感じなんですけどね。

fourthline commented 3 months ago

フリースタイルジャム用のMMLは「和音にテンポ出力を許可する」設定をOFFする必要があるということでしょうか。 知らないとそもそも設定変更しないと思いますので、明示的にオプションとして「フリースタイルジャム用」とかを追加してもよいんじゃないかと思いました。

MML出力時のオプションとなると、必ずしもメロディにテンポを固定できない場合があります。 v1.5.4より前のバージョンはメロディにのみテンポ出力できることが前提でしたが、 v1.5.4ではメロディのみのテンポ出力が前提となっていないため、データによってはメロディのみにテンポ出力することができない場合があります。(悩) ただその場合はエラーメッセージを表示して、チェックがONにならないようになるくらいかな。

Colimoceise commented 3 months ago

まず前置きをさせていただくと、新しいバージョンでつくったMMIファイルを古いバージョンで読み込んだ場合に、意図したとおりになる保証はまったくない、という点は理解しています。 MMIファイルを、作成時とおなじバージョン、あるいはそれより未来のバージョンのMabiIccoを使ってひらく場合に話を絞ります。 また、フリースタイルジャムの件は、例として出しただけです。フリースタイルジャムで問題が起きないようにする出力オプションが欲しい、という話がしたいのではなく、MabiIccoユーザーがMMLを「正確に」やりとりする為にこういう機能があれば、というのが提案の焦点です。

そして、よくよく考えてみたら、「設定によるMMLの出力の違いが問題になる場面は、ほとんどない」というのは間違いでした。 「メロディパートの音符が途中でちぎれてしまうのを避ける為に、和音パートのほうにテンポを置くべき場合」 のほうが、フリースタイルジャムなどより、ずっとよくありそうな例だと気がつきました。 その場合、「和音にテンポ出力を許可する」をオフにして出力したMMLをゲーム内で弾いたときに、意図しない発音になるでしょう。 それは、作譜者自身が書き出すなら、単に気をつけていればいいだけのことですけれど、他人のMMIファイルをもらって使う際に、MML書き出し時にそれらの設定をどうすべきかについて、ファイルをひらいてピアノロールを眺めただけでは簡単にわからないのではないでしょうか。

それからフリースタイルジャムの件は、打楽器と鳥ペット(ヤイロチョウなど)との組み合わせによる演奏でも同様にあてはまります。和音パートにテンポ指定があると、鳥ペットのほうは読み取り、打楽器のほうでは読み取らず、ずれが出ます。 テンポ周りのことに限らず、まだ知られていない仕様(あるいはバグ)による落とし穴がないともいいきれません。(今後のアップデートでそういう落とし穴がもっと増えるかもしれないし。) ピアノロール上では違いがなくても、書き出すMMLのちょっとした差で、ゲーム内で弾いたときに、そういった違いが生まれることがあります。

MabiIccoの設計思想は、あくまでMML制作のしやすさの向上に重点があって、MMLの保存性についてはそこまで優先していない、と、勝手にわたしは想像しています。 でも、あるバージョンでつくったMMIファイルから、おなじバージョンで(もしくは可能なかぎり未来のバージョンでも)、MML@形式の文字列がいつも完全一致で書き出せるという保証があれば、上記のようなことを気にする者にとってうれしいことだと思います。

最適化済みのMML@形式の文字列を、TXTファイルなどで別途管理するのが、結局はいちばん確実です。ただ、そこまでしているひとは少ないと思います。MMIファイルだけで、そういうカッチリした管理ができるようになれば、MabiIccoユーザーにとって安心感が高まり、便利になると思います。 MabiIccoではそんな需要まで請け合えない、将来のバージョンでも互換性を保てるかわからない、ということがはっきりしているならば、この提案はしりぞけていただいてかまいません。

どう機能を実装するかの話よりも先に、その点を明確にしておくほうがよさそうです。MabiIccoが目指しているものからかけ離れた要望なのかどうかが、わたしにはわかっていないので。

ともかく、フリースタイルジャムに限った話ではないから、それ専用のオプションを新設する、というのは、わたしの本意ではありません。 「和音にテンポ出力を許可する」オプションのところに「(フリースタイルジャム用ならオフ推奨)」と書き添えるくらいならいいかもしれません。ただ、それだとメニューがみにくくなりそうです。ヘルプ類に注意書きをするくらいで良いかとも思います。 非常に限られた需要の為に、MabiIccoの設定項目が複雑になることも、あまり望んでいません。

Lisedrika commented 3 months ago

専用オプションの新設を望んでいなかったとおっしゃいましたが、現在あなたが指摘した部分はそれ以外に選択肢がありません。 他にはフリースタイルジャムおよび言及された鳥などの状況を全て無視して考慮しない方案だけだからです。

「和音にテンポ出力」の機能改善アップデートを提案したのは、メロディが切れるのを直すためではありません。 もちろんその部分も直りましたが、それが根本的な目的ではないという意味です。 音符の音をずっと維持しながらも、テンポが変化に富んだ表現技法を具現することができるからです。

和音にテンポを入力する技法は、マビノギMMLの基本仕様なので、劇の序盤からこれを使った楽譜が着実に製作されています。 今この瞬間でもテンポ調整の細かさを気にするユーザーなら、一人用の楽譜でもこの手法を積極的に活用します。 逆にフリースタイルジャム、鳥が少なくとも10年は後にアップデートされたコンテンツです。

ですから、根本的な前後関係を考慮しても、あなたが言及した「作業者以外の他人がMMIファイルを開いたときの保存性(?)」を考慮しても、実は和音のテンポ出力機能はOn/Offではなく基本仕様であるべきだった部分です。

繰り返し強調しますが、3MLEやインゲームで直接編集をしても可能なテクニックです。 厳密に言えば、MabiIccoのバージョンの問題とはかけ離れた指摘であり、該当機能のアップデート以前/以降のMMIファイルの互換性は難しいという部分も明確に公示されています。

そして、「(フリースタイルジャム用ならオフ推奨)」部分はそのように警告文だけを貼る簡単な内容ではないかもしれません。 すでに新しいバージョンをベースに作られた楽譜なら、出力前に機能Offをしても楽譜を昔のバージョンのアルゴリズムどおり再生成する過程まで経てこそ、フリースタイルジャム用楽譜をクリップボードで出力することができます。(fourthlineさんの回答がその部分の困難さを意味するものと予想されます。)

実は「MMLの保存性」を根拠にするならば、逆に最新バージョンがその目的性により合致すると思います。 昔のバージョンは、和音をテンポに挿入した楽譜を正常に読み込んだり、編集したりすることもできなかったし、新しく作ることもできなかったからです。知人同士で楽譜をやりとりする時も「最新バージョンで楽譜を作って(出力して)渡してください」で対話が終わり、これ以上複雑な内容が交わされたことはありませんでした。

何かこれ、スムーズに説明するのが難しい部分ですね。 哲学的というか。(;´・`)>

fourthline commented 3 months ago

対応案としては下記を考えています。 ・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」を追加

現状では通常の演奏/合奏でテンポを和音に出力してもよい理解です。 フリースタイルジャムについては、私は使ったことがないのでちょっと状況を把握していませんでした。 mmiファイルに「テンポをメロディに限定する」かどうかの情報を書き出せば、ファイルのやり取りでも反映できるかなと思います。

Colimoceise commented 3 months ago

その対応案自体は賛成します。「Nコマンドを使用しない」とおなじような位置づけにするということですね。 でも、「和音にテンポ出力を許可する」をトラック単位の紐づけに変更できるのなら、「MML最適化レベル」「mabi32: V0テンポ補正」「mabi64: 合奏ズレ補正」などもそのような仕組みに揃えることもできるのではないでしょうか。 MML出力に関わる設定があっちにあってこっちにもあって、という印象を持っていたので、すべてトラックに紐づけられるなら、すっきりとしそうです。でも、ほかのユーザーにとってそれが便利かどうか、まだ一括指定のほうが好まれるのか、わたしにはよくわからないところです。 それで、機能追加による影響が少なそうに思える、「保存時の設定を表示だけでもできるようにする」という形で提案を出したわけですけれど、無理なく上記のような実装が可能なら、そのほうがいいですね。 それらすべての設定をトラック単位に分けてうれしいケースがどれくらいあるかというと、実際ほとんどないのかもしれませんけれど、すくなくとも打楽器に「mabi32: V0テンポ補正」を適用すると、演奏モーションがずれるのを防げる効果があります。 (現仕様では、テンポ指定直前の休符をすべて無視しているかのように、たとえば「crrt120rc」だったら、楽器を叩く動作だけ「ct120rc」のように振る舞う。演奏される音そのものについては影響なし。) テンポの直前に無音の音符を自力で加えてもいいでしょうけれど、「mabi32: V0テンポ補正」が打楽器パートにのみ適用できるのなら、そのほうが便利だと思います。(項目名は変えたほうがいいのかもしれません) ただ、このあたりになってくると、作譜者の意図うんぬんとは離れた話のような気もしますし、気にしているひともいないように思えるので、これまであまり強く主張しませんでした。フリースタイルジャムなどの件に限らない、と繰り返したのは、このようなこまごまとした点も念頭にあってのことでした。

Lisedrika commented 3 months ago

それがです。 そのバグは最近フィックスになりました。 テンポのためのv0はもう使わなくてもいいです。

ただ、このゲームの開発陣がバグを復活させた前例があるので、機能は残しておくことで相談しておきました。

fourthlineさんの案には賛成です。

Colimoceise commented 3 months ago

わたしがいっているのは、かつての「テンポ指定の直前が休符の場合、実際のテンポ変更が休符の前のタイミングになってしまう」現象のことではありません。打楽器の演奏モーションが演奏音とずれるという話です。すくなくとも日本のマビノギでは現在、先述したようなケースで演奏モーション(打楽器を打つ動作)のタイミングが前にずれます。些細なことですけれど、わたしには気になる点なので取り上げました。

Lisedrika commented 3 months ago

わたしがいっているのは、かつての「テンポ指定の直前が休符の場合、実際のテンポ変更が休符の前のタイミングになってしまう」現象のことではありません。打楽器の演奏モーションが演奏音とずれるという話です。すくなくとも日本のマビノギでは現在、先述したようなケースで演奏モーション(打楽器を打つ動作)のタイミングが前にずれます。些細なことですけれど、わたしには気になる点なので取り上げました。

その部分も矯正されたと知っていますが、復活したとか、サーバーごとに少しずつパッチの事情が変わったかもしれません。 表記の必要性論議とは別にしても、該当現象が起きているという部分は理解しました。

Lisedrika commented 3 months ago

余談で「mabi32: V0テンポ補正」と「mabi64: 合奏ズレ補正」のオプションも今後大きな変動がないはずなので、現状を維持した方がいいですし、それともデフォルトにした方がいいと思います。

このようなオプションを共通オプションではなく個別トラックにすると、これが何であり、なぜon/offをしなければならないのかから勉強しなければなりません。(私もご希望の方には細部の講義をしていますが、大多数はそこまでは敢えて知りたがらないので..)

ローレベルの楽譜最適化の話題がありますが、初心者のユーザーが(別に複雑な理論を勉強しなくても)できるだけ簡単に使えるようにすることが望ましいと思います。

fourthline commented 3 months ago

下記はアプリ設定で維持しようと考えています。

打楽器の演奏モーション用対策として「V0テンポ補正」が必要ということでしたら、トラックオプションに追加でよいかなと思います。

対応案(改)

・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」 (ツールチップ:フリースタイルジャムでON推奨) を追加 ・トラックオプションに「V0テンポ補正」(ツールチップ:打楽器演奏モーション対策用)を追加 image

MML保存性について

MabiIccoとしては最終出力されるMML文字列を保持しないです。 MMLのバグがなおったり、新たにバグが発生したりという場面になったときに、設定変更あるいはVerUpで対応したいなというところがあります。 今後またバグ復活しないとも限らず。 オプション化せず削除したバグ対策用MML補正もあります。 MabiIccoを最新化したときに、MML補正の変更がそのまま反映されたり、最適化が向上していたり、最終出力されるMMLは柔軟にしたいと思っています。(MMLを重視する方からすると、勝手に出力MML変えんなや・・・なのかもしれませんが)。 現状MML文字列として保管しておきたいとなった場合は、手でtxt等へ変換していくことにはなると思います。

mmiファイルにMabiIccoの設定値を保存しても、将来のMabiIccoが同一のMML文字列を出力するのはちょっと難しいです。 最終出力されるMML文字列の保管となると、

あたりかなと思います。

Lisedrika commented 3 months ago

保存性についての部分は、その定義から始まっていろいろ難しい部分だと思います。

私の個人的な意見を申し上げますと、現在MabiIccoの(特定の基準に合わせて自動化された)処理方式が「アクセシビリティ」、「新規ユーザー創出」の面で非常に得が多いと思います。

保存性を少し放棄しても、上記のメリットが得られれば大丈夫だと思います。 そして、私にはその部分が気分的に不便な点はありません。 コードの保存よりは円滑な作曲、演奏、音楽活動が本質だと思うので、音が同じだという仮定の下、バージョンアップによる若干の変化はいくらでも収容できます。

実際、楽譜の保存性と作業の利便性は両立しません。 TXTファイルを直接作成してやりとりすること以外には根本的な解決は不可能だと思います。 すでにいろんなところで自動処理されていて、ずっとアルゴリズムのアップデートと改善が行われていますからね。 (これはいつも感謝している部分です ⸜( ˙ ˘ ˙)⸝♡)

もちろんバグの部分は改善が必要なので、新しい機能が追加されても例外ですね。 なるべく簡単に書けるようになって、簡単に説明できたらいいな~ 同じ意見はあります。

Colimoceise commented 3 months ago

MabiIccoの開発の方針が伺えたので納得できました。ありがとうございます。

そうであれば、この提案は棄却していただいていいのですけれど、話が進んでいるようなので、「和音にテンポ出力を許可する」の移設については反対する理由はなにもありません。それに比べると、「V0テンポ補正」は、あとでまた触れますけれど、わざわざトラックごとの設定項目に変えるべきかどうか、かなり疑わしいです。

もとからわたしも、ユーザーが『これが何であり、なぜon/offをしなければならないのかから勉強しなければ』ならなくなることを危惧して、多くのユーザーにとってじゃまにならないような小さい機能を提案したわけで、フリースタイルジャム専用の新しい設定項目は要らない、と答えたのもおなじ理由です。

『(編集ロック)のような機能』、あればいいなと思います。今後期待しています。 議論は終わったとして、最後にもうひとつだけ、わたしが「MML@文字列が変わらないこと」についてしつこく述べた理由について、つけ加えさせてください。 バージョンを更新したらMML@文字列の出力が変わり得るので、念の為に古いバージョンのMabiIccoをいくつも保存している、というひとを複数人、知っています。(おもに文字数の変動がその理由のようですけれど、バージョン更新後にMMLを書き出したら演奏内容にも変化があった、またはあるような気がした、という声もたまに聞きました) もちろん改善による変化だと皆さん知っているわけですけれど、それでもたくさんのバージョンのMabiIccoを持っておかないと不安だ、という状況はあまり健全とは思えないのです。 ……というのも問題意識のひとつでした。もちろん今回の提案だけで解消できることでもなく、もっと大きな提案にならざるを得ず、さすがにそれは遠慮してしまいます。そして、開発方針も伺えたので、上記の点は仕方ない、と捉えることにします。

Colimoceise commented 3 months ago

打楽器とテンポの件の補足。文章だけで伝えられているかが不安なので、念の為、動画を用意しました。

https://github.com/user-attachments/assets/afaa55cb-69b5-4191-b17f-a2c9940aeec8

前半 ① MML@t120r1ccccr1cccc; 後半 ② MML@t120r1ccccr1t120cccc;

動画で確認できるとおり、②の場合、「r1t120」の「r1」を無視したような、見た目の動作になっています。演奏音は①も②も同じです。

そして、このことについて、MabiIccoの機能で解決したい(解決すべき)と考えているわけでは全然ありません。 MabiIccoのユーザー各人の設定の違いで、ゲーム内での演奏時に思わぬ違いが生まれることがある、という一例として触れただけに過ぎません。 この現象を気にするひとは、オプションがなくても、自力で無音音符をテンポの前に置くことでしょう。 「mabi32: V0テンポ補正」をトラックごとに紐づける意味はゼロではない、それはそれで便利に使うことはできそう、という程度のことです。(一方、たとえばMML最適化のレベルをトラックごとに紐づけるメリットはまったく思いつきません。)

Lisedrika commented 3 months ago

MabiIccoの開発の方針が伺えたので納得できました。ありがとうございます。

そうであれば、この提案は棄却していただいていいのですけれど、話が進んでいるようなので、「和音にテンポ出力を許可する」の移設については反対する理由はなにもありません。それに比べると、「V0テンポ補正」は、あとでまた触れますけれど、わざわざトラックごとの設定項目に変えるべきかどうか、かなり疑わしいです。

もとからわたしも、ユーザーが『これが何であり、なぜon/offをしなければならないのかから勉強しなければ』ならなくなることを危惧して、多くのユーザーにとってじゃまにならないような小さい機能を提案したわけで、フリースタイルジャム専用の新しい設定項目は要らない、と答えたのもおなじ理由です。

『(編集ロック)のような機能』、あればいいなと思います。今後期待しています。 議論は終わったとして、最後にもうひとつだけ、わたしが「MML@文字列が変わらないこと」についてしつこく述べた理由について、つけ加えさせてください。 バージョンを更新したらMML@文字列の出力が変わり得るので、念の為に古いバージョンのMabiIccoをいくつも保存している、というひとを複数人、知っています。(おもに文字数の変動がその理由のようですけれど、バージョン更新後にMMLを書き出したら演奏内容にも変化があった、またはあるような気がした、という声もたまに聞きました) もちろん改善による変化だと皆さん知っているわけですけれど、それでもたくさんのバージョンのMabiIccoを持っておかないと不安だ、という状況はあまり健全とは思えないのです。 ……というのも問題意識のひとつでした。もちろん今回の提案だけで解消できることでもなく、もっと大きな提案にならざるを得ず、さすがにそれは遠慮してしまいます。そして、開発方針も伺えたので、上記の点は仕方ない、と捉えることにします。

正直、編集ロックをはじめとする一連の内容がどんなことを意味するのかは今でもよく理解しにくく、なぜあるべきなのかもすっきりとは納得できません。 提案者も各種改善を積極的に主張されないのでもっと混乱しますね···

バージョンを更新する際、最適化アルゴリズムの変化で楽譜の内容が変わることはありますが、経験上、実際に演奏した時の結果、つまりサウンドには影響がありませんでした。 むしろ、新バージョンで何かオプションを間違えて触ったり、同時発音の数のアップデートによって聞こえなかった楽器の音が聞こえるようになることを疑うのがより合理的です。 (ほとんどは再生性で解決しますが。)

もちろん、そのような迷信に近い不安感(?)から始まってアップデートが煩わしいとか、Low-levelレベルの直接編集が良いとか、あらゆる理由で旧バージョン、さらには3MLEをそのまま使う方もいます。 もちろんそれなりの長所もあるので、あえて彼らの意思を変えるつもりはないのですが、はっきり言って極少数ですよね。本当に不安でしたら、そのまま旧バージョンをお使いになっても、特に問題はないと思います。 お互いに同じバージョンを使いながら交流するという協議が必要でしょうが。

編集ロックは、実際の楽譜内容の変化があってもなくても、ユーザーをバージョン別にさらに断片化させることができるという危険要素があり、反対します。 (各ユーザーごとに特定のバージョンで編集することを強要する様子も予想できるので)

ある番組が継続してアップデートされているのであれば、ユーザーもそれに歩調を合わせてついていくのが正しい姿勢だと考えています。

Colimoceise commented 3 months ago

わたしがここでいま提案している(していた)のは「MML書き出しに影響する設定をMMIファイルに記録する機能」です。『各種改善を積極的に主張』しないのは、それらのアイデアを積極的に伝えるなら別のイシューを立てるのが筋だからです。 背景となる考えをたくさん説明したぶん、すでに本件の範囲を超えて書きすぎていると思っているくらいです。 MabiIccoの開発方針を確認したので、今回の提案は棄却してもらってよい、とすでに述べました。現状のままでよいのです。 でも、「和音にテンポ出力を許可する」のを基本の動作とし、トラック単位でオプトアウトできるようにする、という話について、ここで議論している3人とも賛成しているのだから、その部分まで棄却する必要はないと思っています。 それ以上、「各種改善」を持ち出す気はありません。 「『(編集ロック)のような機能』、あればいいなと思います。今後期待しています。」と書いたのは単なる気持ちの表明です。誤解を生む書きかただったかもしれませんけれど、ここで内容を議論しようとはしていません。もし将来そういうイシューをだれかが立てることがあったら、そこで反対してください。

Lisedrika commented 3 months ago

わたしがここでいま提案している(していた)のは「MML書き出しに影響する設定をMMIファイルに記録する機能」です。『各種改善を積極的に主張』しないのは、それらのアイデアを積極的に伝えるなら別のイシューを立てるのが筋だからです。 背景となる考えをたくさん説明したぶん、すでに本件の範囲を超えて書きすぎていると思っているくらいです。 MabiIccoの開発方針を確認したので、今回の提案は棄却してもらってよい、とすでに述べました。現状のままでよいのです。 でも、「和音にテンポ出力を許可する」のを基本の動作とし、トラック単位でオプトアウトできるようにする、という話について、ここで議論している3人とも賛成しているのだから、その部分まで棄却する必要はないと思っています。 それ以上、「各種改善」を持ち出す気はありません。 「『(編集ロック)のような機能』、あればいいなと思います。今後期待しています。」と書いたのは単なる気持ちの表明です。誤解を生む書きかただったかもしれませんけれど、ここで内容を議論しようとはしていません。もし将来そういうイシューをだれかが立てることがあったら、そこで反対してください。

返信ありがとうございます.

改善に対する様々な方案を悩んで文を書くことは分かりました。ただ、会話が長くなったので、仕方なく今具体的な改善を要請する部分と、非常に複雑な議論が必要な部分、単なる気持ちの表明などが明確に区分されていなかったと思います。

おっしゃったように、現在fourthlineさんのご提案された案には同意しておりますので、話題がまとまっているこの時点で、ある程度交通整理が必要ではないかと思い、追加でお話しした部分でした。

fourthline commented 3 months ago

ちょっと私も話しの流れについていけてないのですが...

今のところ下記のつもりです。

対応案(改) ・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」 (ツールチップ:フリースタイルジャムでON推奨) を追加 ・トラックオプションに「V0テンポ補正」(ツールチップ:打楽器演奏モーション対策用)を追加

ただ、打楽器演奏モーション対策用はちょっとまだ中身を把握しきれていないところがあるので、ゲーム内で別途確認しようかなと思っています。なのでまだ時間を要する内容です。

また混乱させてしまい申し訳ありませんでしたが、下記の件は現状で具体的になにか検討しているというものではありません。

  • 85 のNo.5のようなtxtへのExport機能か

  • 最終出力されるMML保持(編集ロック)のような機能か
Colimoceise commented 3 months ago

繰り返しになってしまいますけれど、「V0テンポ補正」の部分については、トラック単位の紐づけに変更するほど重要だとは、いま思っていません。 これまでたくさん書いてきた途中で、各設定をまとめてトラック単位にできないか、という話をさせていただきましたけれど、それは開発方針とうまくマッチしないとわかりましたし、やりとりを経た現段階となっては、そういう案はもう引っ込めています。「V0テンポ補正」をトラック単位に分ける件も、そういう話の流れのなかで持ち出したことで、いまはそれも含めて断念しているところです。

わたしは先月くらいに、「和音にテンポ出力を許可する」オプションに関する楽譜のやりとりの失敗(フリースタイルジャムで打楽器がずれるという話)を経験し、それが今回の提案の直接の動機になりました。だから、(仮にほとんどの演奏家にとって些細なことであっても、)このオプションの移転については賛成しています。 一方、わたしの知るかぎり、打楽器の演奏モーションがずれる、という話はだれひとり気にかけていません。実害もほとんどありません。そもそも、ドラムセット実装以来、シロフォン以外の打楽器が用いられることもかなり少なくなっていますし。 需要の点から見ても、「mabi32: V0テンポ補正」のまま、しばらくは現状維持の仕様で、とくに問題ないと思っています。変更する理由はあっても、変更するほどの理由がない、とでもいえばいいでしょうか……。 でも、最終的にそのあたりはお任せいたします。変更しないで、と強くお願いするのも妙な気がするので。

Lisedrika commented 3 months ago

ちょっと私も話しの流れについていけてないのですが...

今のところ下記のつもりです。

対応案(改) ・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」 (ツールチップ:フリースタイルジャムでON推奨) を追加 ・トラックオプションに「V0テンポ補正」(ツールチップ:打楽器演奏モーション対策用)を追加

ただ、打楽器演奏モーション対策用はちょっとまだ中身を把握しきれていないところがあるので、ゲーム内で別途確認しようかなと思っています。なのでまだ時間を要する内容です。

また混乱させてしまい申し訳ありませんでしたが、下記の件は現状で具体的になにか検討しているというものではありません。

  • 機能改善提案 #85 のNo.5のようなtxtへのExport機能か
  • 最終出力されるMML保持(編集ロック)のような機能か

いろいろな状況への対応を考えると、おっしゃるとおりに処理した方がいいと思います。 MML出力時に対応する案は、どうやら想定外の複数のリスクを伴うようですね。

fourthline commented 2 months ago

打楽器演奏モーション対策用

私もゲーム内で確認してみました。演奏自体には影響なく、モーションのみの影響ということで理解しました。 気にされている方も限定的ということなので、トラックオプションでよいかなという考えです。

テストバージョンを作成してみました。 v1.5.4+to

対応案(改) ・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」 (ツールチップ:フリースタイルジャムでON推奨) を追加 ・トラックオプションに「V0テンポ補正」(ツールチップ:打楽器演奏モーション対策用)を追加

image

Colimoceise commented 2 months ago

ちょっとさわった限り、新設のトラックオプションは問題なく機能しているようでした。

トラックオプションとして「V0テンポ補正」を加えた上で、全体オプションの「mabi32: V0テンポ補正」も残しておくんですか? 組み合わせが4通りになりますね。

という振る舞いになっていて、言葉でこのようにまとめると納得いくのですけれど、ソフトのUI上ではそこまで把握がしづらいように思います。 トラック側の「V0テンポ補正」だけ、今後さらに性能を改良する可能性があるから、従来のほうも残す、ということでしょうか?

Lisedrika commented 2 months ago

開発陣がMMLのバグを復活させた事例が何度もあったので、「mabi32:V0テンポ補正」は残しておいたほうがいいと思います。

そのようなことが再び起きた時、多くのユーザーの要求を早く静めるためには「mabi32:V0テンポ補正を活性化してください」という簡単な一言伝達事項が切実でしょう。

普通のユーザー基準なら、オプションを常時オンにしておいた方が長期的な安定性の面で有利でしょうね。

fourthline commented 2 months ago

「mabi32:V0テンポ補正」はそのままにします。 用途が異なり、こちらはゲーム内のバグ対策用です。現在はONの必要はない認識ですが、今後再発する可能性を否定できないためです。

Colimoceise commented 2 months ago

「mabi32: V0テンポ補正」は残すとして、わざわざトラックオプションにも「V0テンポ補正」を新設する必要がほんとにあるのかどうか、というのがわたしの懸念です。 ユーザーのみなさんがこの機能を歓迎するのかどうかについては、わたしには判断できませんから、わたし自身の感覚でしかいえませんけれど、似たオプションがあちこちにあると、さっき書いたように組み合わせも複雑になり、混乱してしまうように見えます。 トラックオプションの「V0テンポ補正」が別用途として区別され、「打楽器モーション対策に特化した機能」となるのなら、以下の振る舞いを望みたいところです。

でも、すでに今回の提案の範囲を超えすぎているので、ひとまず、トラックオプションの「V0テンポ補正」のほうに将来、なにか改良が加わっていく予定があるかどうかだけお尋ねしたいです。予定がおありでしたら、v1.5.4+toのバージョンで異議ありません。予定がなければ、「V0テンポ補正」を急いで実装する必要を感じない、というのがわたしの思うところです。

fourthline commented 2 months ago

トラックオプションの「V0テンポ補正」のほうに将来、なにか改良が加わっていく予定があるかどうかだけお尋ねしたいです。

予定はありません。

打楽器モーション対策としては、「V0テンポ補正(メロディパートのみ)」「長い休符の途中にv0音符」が必要ということですね。であれば、そういった機能のほうがよいかなと思います。ここで議論する話ではないのですが、ON/OFF設定なしでデフォルトのMML補正機能でよいのかなという印象です。

トラックオプションの「V0テンポ補正」はいったん外しておきます。

対応案(改) ・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」 (ツールチップ:フリースタイルジャムでON推奨) を追加 ~・トラックオプションに「V0テンポ補正」(ツールチップ:打楽器演奏モーション対策用)を追加~

Colimoceise commented 2 months ago

なるほど。わかりました、賛成です。 長い長いスレッドとなりましたけれど、御検討いただきありがとうございました。

Lisedrika commented 2 months ago

トラックオプションの「V0テンポ補正」のほうに将来、なにか改良が加わっていく予定があるかどうかだけお尋ねしたいです。

予定はありません。

打楽器モーション対策としては、「V0テンポ補正(メロディパートのみ)」「長い休符の途中にv0音符」が必要ということですね。であれば、そういった機能のほうがよいかなと思います。ここで議論する話ではないのですが、ON/OFF設定なしでデフォルトのMML補正機能でよいのかなという印象です。

トラックオプションの「V0テンポ補正」はいったん外しておきます。

対応案(改) ・和音にテンポ出力を許可する設定を廃止、ONで固定 ・トラックオプションに「テンポをメロディに限定する」 (ツールチップ:フリースタイルジャムでON推奨) を追加 ~・トラックオプションに「V0テンポ補正」(ツールチップ:打楽器演奏モーション対策用)を追加~

デフォルトオプションにする場合に発生する「以前のバージョンで製作した楽譜との互換性」問題が懸念されます。

もし楽譜分量の限界に合わせて作業した楽譜なら、新しく読む時に新しい文字が追加されて困る状況が生じるのではないでしょうか?

アップデートをする時、ユーザーにこの部分についての案内告知が行われるといいですね。 (お知らせがあればアップデート自体には特に異論はありません。)