すたどんたんが一発当たったようだけれど どうせなら、単なる一発ネタではなく、 持続的に、普通に音楽メモとして使われる 普遍的なツール/手法として育てたい。 （出来れば教育用途にも使ってもらいたい）
例えば、SiON系列とFlMML系列のサイトが全て相互リンクしたとして、 シナジーって生まれるのだろうか。
文法も違うし、文化も違う訳だけれども…
例えばあるMMLサービスを使っている時に、 音作りをしたい、簡単にドラムを鳴らしたい、楽譜を作りたい と思ったその時、ボタン一つでMMLを別のサービス上にペーストできる ような機能があれば、便利かもしれない。
すたどんたんは独自部分が多いので、自分がそういうのを提案するのはどうかと思うけれど… やるのであれば、GETパラメータにMML本体を含める形のインターフェースを 各サービスで提供すれば、相互運用性は確保出来るはず。
「ぽてぽて」「ほむほむ」などの擬音語をオノマトペという。
昔からオノマトペ記述は利用されている。 http://www.vesta.dti.ne.jp/~hokaboko/ohayasi.html
http://abesha.sns.fc2.com/exec/member/blog/view/9426/?sid=3a1dca5cd672b6314cadbd2673aa4fa46589dba3
http://homepage3.nifty.com/k_tomita~s/romarin/data/Onomatope/Onomatope_04_ta.htm
2011.06.01に人工知能学会で行われたオノマトペセッションの論文一覧。 https://kaigi.org/jsai/webprogram/2011/session-144.html
英語圏だと、繰り返しを使ったオノマトペは赤ちゃん言葉と認識されていると聞いたことがある。
すたどんたんは当初から、2文字以上のサンプル置換を検討していて、 背景には「オトマノペマッピング」と命名したアイデアがある。
これは、ベースやパーカッションを一通り録音しておいて、 その録音に対し、オトマノペでふりがなを振っておく。
ベースだったら「べーーべっべっぺんべっべぺっぺえ」のような形。 それを延々とベーシストに演奏してもらい、ふりがなを振っておく。
振ったふりがなを辞書として使い、 例えばユーザが「ぺっぺぺっぺ」と入力したら、 「べーーべっべっぺん【べっべぺっぺ】え」 の部分を抜き出して再生するようにする。
この方法による利点は、 ・ベーシストの手癖を素人が利用できる ・タメやスライドなどを反映でき、自然な演奏感を得られる
問題点。 ・最長一致検索のコスト（方法もよくわからない） ・データを用意する手間 ・辞書で重複部分が多発 ・ユーザが音程を制御できない ・スラップベースぐらいにしか適用できない？
問題点を無視するためには、 ・そもそもユーザに音程を制御させない（ベースの場合、音程感がない低域で演奏してもらう） ・リズムとクリシェのみで楽しんでもらう
そもそも、実働サンプルなどで検証しないことには、効果の程も分からない。 手で辞書を作成した簡易版を作ろうかと検討中。 （ハンマリングは普段１度か２度のインターバルでしか行われないことを考えると クリシェのパターンは限られているような気がしてる）
そもそもtabla bolやらディドルやらストトン記法やらは既知のアイデアなんだから オノマトペマッピングそのものが既知のアイデアの可能性はあるけど…
MML自体が生き残るために、余分な糖衣構文は捨て去らないといけないし、音源のモジュール化も必要だろう。それをしないとBMSが生き残ってMMLが絶滅する世界が本当に来そう。
以下はkeimさんの指摘。
mmlの弱点 ・１シーケンス１チャンネルが前提． ・統合作製環境が無い． ・視認性が低い． mmlの良い点 ・テキストベース(軽量，可搬性，インターネットとの親和性，好きな作製環境を選べる等)． ・表記の圧縮率の高さ．それによるビックリ箱要素． ・「視認性の低さ」からくる職人芸と，それによる承認欲求の充足度の高さ．
・１シーケンス１チャンネルが前提．
これは、一対多、多対一のソリューションがサクラになかったっけ…。 １チャンネルにつき同時発音が１音という意味合いであれば、カットアップでの制作に使ってもらうというやり方もあるのかと思う。
・統合作製環境が無い．
統合作製環境が必要になる規模のMMLを書くべきでは無いと思う。ピコカキコやすたどんたんに見られるように、マイクロコンテンツの方がMMLの対象範囲に近い。 …なんて言うと、多分昔ながらのMML書く人には怒られる気がする。量を書いてスゲー感出す人いるからな。自分は小さいファイルサイズで曲を作る方が、昔から好きだけど。
・視認性が低い．
まずは糖衣構文の排除。ストトン記述＋多少のGUIを採用することで、「何をしているか分かりやすい」DAWとしてアピール出来る可能性がある。
・テキストベース(軽量，可搬性，インターネットとの親和性，好きな作製環境を選べる等)．
MMLが書けるエディタというのは今後作られない可能性が高いので、Webエディタに移行するのがいいと思う。この点においては、どんなDAWにも先行できる。
・表記の圧縮率の高さ．それによるビックリ箱要素．
プリセットをうまく利用することで、びっくり箱的な印象を強めることが出来る（→すたどんたん）
・「視認性の低さ」からくる職人芸と，それによる承認欲求の充足度の高さ．
俺スゲー感は満たされると思うけれど、広く公開して理解が得られなければ、承認欲求も内輪から得られるものだけにとどまってしまうのではないだろうか。
◆その他問題点
未だに音色をMMLでうまく書く方法がない。 FM音源が最もコンパクトかも知れないけれど、ワンショットサンプルを使いたいような時が頻繁にあるし、 140文字で収まるわけではない。 また、歌モノを作りたい時はどうするのか…？ 理想を言えばUTAUの組み込み、もしくはカラオケ録音がFlashインターフェースから使えればいいが…
今、WebベースのMML再生ライブラリにはSiONとFlMMLがある。SiONはActionScriptでインタラクティブに音を扱う場合に使われ、FlMMLはピコカキコなどに広く使われている。
どちらのライブラリの文法も、TSS(CP)というWebMML再生ツールを参照しているようだ。そのため、2種類のMMLが共存しているにもかかわらず、WebMML界は健全な状態にあるんだと思う。
３年くらい前に、MMLの共通文法を作りたいんですよね、という話を上の年代の人に語ったんだけど、「難しいんじゃない？」という風に言われてしまった。でも、自分の認識では、共通化出来ないこと自体がおかしいと思っていた。
音楽は音色、音量、ピッチの3要素で構成されている。音色はハードウェアに依存するだろうけど、それ以外の二つは分離できればMML上で共通化できる。
（音色変化とシーケンスが入り組んでいる場合は難しいだろうけど、Yコマンドを使えるMMLユーザなんて一割も居ないと認識してる。正直、ちゃんと使ってる人なんて1%って所じゃないだろうか。）
大体、ループやオクターブ上下のような、シーケンスの根幹部分に対してのデファクト形成の動きが無かったのが不思議だ。その時代なりの事情があったんだろうか。たしか、MMLの源流が分かれてるとかは聞いたけれど。
共通化が難しいという認識が出てくるのは、過去のドライバとMML文法が強固に結びついていたからｄと思う。ただ、そのような機種依存・ドライバ依存のMMLはエミュレータでしか動かなくなるし、いずれユーザが減って誰も書かなくなる。資料が散逸すれば読める人も居なくなる。読めないMMLとバイナリの差異って何だろうか…。
共通仕様を持ったMML文法、という仕事は、最終的にkeimさんが成し遂げた。
http://d.hatena.ne.jp/keim_at_Si/20080618/p1
多分、TSSCP以前の文法を喋るユーザは居なくなるだろうし、自分もSiONとFlMMLを普及する方向で動くつもり。
HTMLのよさって、以下の二点にあると思う。
ただ、上記の二点は相反するところがあるし、実際以下のような問題が起こる。
落としどころとしては、媒体ごとにCSSを用意して切り替えればいいんだろうけど、これは死ぬほど面倒。で、ちょっと考えたのが、Webを縦A4の複数ページで構成してはどうかということ。理由としては以下の通り。
問題点はもちろん
というわけで、やるにしても、普段見てるテキストサイトとかではやられたくない感じ。少なくともCMSとかの形にしないと使ってもらえないだろうな。
MMLは怖い。何がって見た目が。
何だそんなことと思われるだろうけど、この点の重要性に気づいてない人がMMLを広めるのは無理な話だと思う。
これを解決するのは簡単で、
を
に置換するスクリプトを組めばいい。（これはストトン記法、という既知のアイデア）
こういう話を書くと、MMLなんて自分さえ使えればいいと言う風に言われるけれど、その使っているMMLコンパイラを作った人が、自分さえ使えればいいと考えていたかどうか。ある手法から生まれる可能性を最大限に引き出すために、より多くの人に技術を供するほうが良いし、そのためにかみ砕いたシステムを作るのは当然のことだと思う。
今考えているのは「どんどんたんすたすたどんたん」という文字列（ボルという）を最長一致でMMLに変換していく仕組み。トライ＆エラーしながら作っていける時代だから、簡易で直感的な記法には需要があると思う。
発言ソースはなくしてしまったのだが、
「VJの操作しているWindowsの画面が一瞬映ると冷める」
と発言している人が居て、なるほどと思った。確かに広告ディスプレイがブルースクリーンになってたりすると、なんだか裏側を垣間見てしまったような気分になるものだ。
Web、とくにCMSなんかは「見えっぱなし」になっているのが多い。「管理者ログイン」ボタンとか。Made by ～とかね。なぜコンテンツと無関係な記述を隠そうという気が起こらないのだろう。
ナビゲーション、バナー、ヘッダなんかも便利だけれど、絵サイトとか、文章サイト、ゲームサイトでそういうものがあると、雰囲気を損なうのではないか。
新Webは、javascript見れば分かるけど、キーを”１２３４”と入力するとパスワード入力画面が出るようになっている。まだ、CMS然としているけど、雰囲気を統一する必要のあるコンテンツを制作するとき、使う機会があるはずだ。
かとう君と話していたときに、スクリーンエイジ、という言葉が出てきた。スクリーンを見て育った世代という意味らしい。
デジタルサイネージとは、要は電子ポスターのこと。1.5秒程度しかメッセージを伝えられないんでは、現状効果が薄いって事だと思う。秋葉原駅とかにもたくさんあるけど、それらのデジタルサイネージを凝視している人を見たことがない。
そもそも、スクリーンって公共向けの物体なのか？
iPadは個人向けとしてはでかすぎる。たくさんの人に見せるには小さい。人に手渡してWebページや写真を見せるのには便利だ。画面を回転させて見せられるし、使い方も分かりやすい。個人向けなんだか公共向けなんだか分からん物体は面白いと思い、iPadを買うことにした。これが半年くらい前の話。
最初は16次元レコードの曲を詰め込んで、カフェに置いて自由に触ってもらう、という使い方を考えていた。16次元レコード専用の、インタラクティブなデジタルサイネージ（でいいのか？）にしたかったのだ。しかし、そういう使い方をしてもらおうとしても、遠慮されることが多かった。
第一の関門は、おそらく衛生的な問題。自分の物ではないものを、ぺたぺた触るというのは気が引ける行為らしい。（指紋つきまくってるし清潔感はない）
第二の関門は、プライベートを見られることへの違和感。何かを見ている自分を観察されるというのは、気持ちが悪いものだ。これは電車内でiPadを使っているときに実感する。
やっぱり、スクリーンって個人向けの物体なんじゃないのか、と強く思う。
個人向けってことは、気持ち悪い使い方が出来るってことだ。
どう使うか、と考えたときに、「顔として使う」ということを考え付いた。顔はいろんな人に見られるものだけれども、隠すものでもある。スクリーンと立ち位置似てないだろうか。
この辺は、何かやるかもしれないし、やらないかもしれない。やらない公算が強いな。iPad重いし。どうにかならんかこれ…
http://www.16dimensional.com/yh/
音楽は置かずに、絵とゲームのみで構成する。 内部的にはPHPで、フレームワークなどは使わずコーディングした。
以前より「jot」というオンラインメモを内製して使用しており、それを使ってWebの管理を行えるようにしてある。記法はMarkdown形式。
元はSimplenoteと連携を考えていたけれど、ResophNotesの挙動がSimplenoteの更新とともに怪しくなってきたので、結局ベタで書いている。
CakePHPを練習して、高速にWebアプリケーションを作れるようになりたい。オンラインでのLight-weightなコンテンツ制作に可能性を感じている。
目指す雰囲気はシャッツキステ的な、図書の森。