1行のコードからアルゴリズム交響曲 - どのように、そしてなぜ？
この文章はTarkastele kokoさんのブログを訳したものです。精度の高い訳ではありませんので原文などと一緒に読まれることを勧めます。内容はate bitさんが作ったC64のデモにインスパイアされたTarkastele kokoさんがC言語1行で音楽を作り始めた。チャットで数人にこの成果を発表したところGoogle+とか広がって、Javascriptのソフトができてノン・プログラマも参加してきて大きな塊が形成されてハックしあう感じでノウハウが溜まってきた。もしかしたら将来、僕らがやっていることを数学的に説明してくれたら嬉しいな。
>>>それでは本文
1行のコードからアルゴリズム交響曲 - どのように、そしてなぜ？ Tarkastele koko
原文 http://bit.ly/rmkvno
このごろ、音楽のような何かを音響合成するとても短いプログラムでいろいろな実験をしていた。私は今、これらの実験に関する情報や考えを共有したい。
まずは背景から。2011年9月26日に、私は7つのプログラムとそれがどんな風に音になるのかを表した以下の動画をYoutubeにアップした：
このビデオはたくさんの関心を広い、インプパイアされた多くのプログラマは自ら実験し、その成果を共有している。これをさらにBemmuのオンラインJavascriptのユーティリティの後押しによって誰（私は推測するノン・プログラマ）でも簡単に始められるような流れができた。まさにこの2、3日程度でとても多くの式が発見されたので成果を公開すべく別のビデオをアップしなければならなくなった。
すべては私が23バイトのC64のデモ−ate bit氏（4mat）のWallflower−に遭遇した2ヶ月前にはじまった、このプラットフォームでこれぐらいの能力があるのにこれぐらい小さいサイズのものは今まで見たことのなかった。グリッチしていて、しかしこのサイズからは思いも寄らない豊かな音楽構造を持っていた。私は自分自身で実験し始め、16バイトのVIC-20持ち寄り、私の心をうっとりさせる音がなるプログラムを書いた。私の以前のブログ記事"16バイトのフロンティア"でこれらがどう動作するかの発見と推測をレポートしている。
ややあって、私はもう少し科学的なアプローチで実験を再開した。何が起こっているのかをより理解するために、私はシンプルかつ"純粋"な環境を必要とした。8ビットサウンドチップとプロセッサには欠落した固有の癖や隠された複雑さの何かがあるはずだ思った。私は生のPCMオーディオデータをダンプする短いCプログラムで実験することにした。私は以前に小さな"/dev/dsp ソフトウェアシンセサイザ"を書いていた、そして1990年代後半に私のemail/usenetシグネチャを1つ持っていた。しかしながら、このプログラムは私が以前に書いていたものより短く、より予想できない結果をもたらすだろう。
私はまず8bitの経験から本質的なものを模倣してみることにした:波形を生成する、ピッチはピッチシフトを構成する関数と論理演算子によって制御される。/dev/dspのプログラムにとって最もシンプルな波形はのこぎり波だ。単純にfor(;;)putchar(t++)は、256バイトのサイクル長のノコギリ波を生成し、それらからサンプリングレートを8000 Hzを使って31.25 Hzの周波数を持っている。ピッチは乗算によって変更可能だ。t++*2 はオクターブ上、t++*3は7音半上がり、t++*(t>>8) は上昇音を生み出す。2、3の試論で、私が思い付いたものをIRCのチャンネルで共有したくなっていた：
main(t){for(t=0;;t++)putchar(t*(((t>>12)|(t>>8))&(63&(t>>4))));}1時間以上かけて、VisyとTejeezはチャネル上に6つ以上のプログラムを寄稿し、主に定数と一部の関数を変化させた。翌日、VisyのGoogle+で私たちの発見を共有した。私はそれらを再共有。興味深いコメントの驚くべき洪水。一部の人々へMP3にレンダリングした曲を聞かせたかったので、それらを1つにまとめた。これらすべての反響結果が私にテキスト画面を持ったMP3にレンダリングした曲をYoutubeでアップさせたのだ。（不思議に思っているかもしれない、私がもはや存在しないテキストモードのデバイスをシミュレートしたような古いコードの断片をスクリーン上に生成するのを、それは生成した音がFakebit(訳注：音楽のジャンル)のようなサウンドになったから。最初のビデオがアップされたとき、私はまだCコードの1行が初期の8ビットの実験の洗練さに到達するかどうか確信が持てなかった。これらのどこに和音とパーカッションがあるのでしょうか？。素晴らしいベースラインや進行を見つけていたなら、小さなデモシーン制作に役立つだっていただろうが。
この時点で一部の人々は気づいていた、t*の部分を取り除くことにより、そして時間の値をシフトさせるのに論理演算子を適用することでハーモニーとパーカッションのパターンを得られることを。t&t>>8のようなシンプルな式でさえ、"munching squares"の聴覚的な結果、興味深いハーモニック特性を持っている。小さな機能で出力に定数を加算することでラウドな音ができる。簡単な論理演算子でも2つの良い音を出す式を一緒に組み合わせるのに十分だ（多くの場合、音の豊かさを追加する興味深い結果を引き起こす）。これらすべては"second iteration"のビデオが証明してくれる。
このペースで実験が続いたなら、何週間も経ずに非常に短いプログラムで、我々は聖杯を発見してしまうだろう：ポップソングのすべての要素（リズム、メロディー、ベースライン、コード進行、マクロ組織）を一般的に音響合成するのにSpotify（訳注：音楽サービス）のリンクよりも短いかもしれない。もしかするとヴォーカルのようなサウンドも多少は可能かも。
これは以前には存在しなかったのか？
我々は何10年も前からこれらすべての技術を持っていた。人々は、デジタルロジックを操作して音楽の回路を構築し、音楽を生み出すソフトウェアの小さいピースを作成し、カオスなオーディオビジュアルプログラムで実験し、音楽作品のために様々なアルゴリズムを試してきた。音楽の数学的理論は2千年以上の歴史を持っている。これに基づくと、これが気の遠くなることだと知っている、コンピューティングとアルゴリズミックな音響合成にたいする私の非常に長い関心にもかかわらず我々の発見に似たものに遭遇したことがいまのところない。私は関連論文をGoogle Scholarで検索したが何も見つけられなかった。それでも、私は多くの人々が以前にこれらの式に出逢っていると確信している、しかし何らかの理由で発見はあいまいに残されていた。
多分それは単なる技術的ミスマッチだろう：デジタル音楽の回路を構築するために、LFSRのようなものが非常に幅の広いシーケンシャルカウンタよりも魅力的に思われていたかもしれない。マイコンの初期の時代には、既に音楽的構造を保持するのに利用できる十分なRAMがあったので、シンプルなロジックでそれをシミュレートする衝動が起きなかった。前衛芸術的な思考傾向の問題について：あなたがランダムな回路構成や奇妙なビットシフトの式を試みたいなら、グリッチの美学を鑑賞することを学んでいるようなら、それをはるかに越えるような技術的な要求は決してない。
デモシーンは技術的なミスマッチとは無関係に、この特別な位置にいる。ギガバイト、テラバイトの時代でも、デモシーンのプログラマはこれまでより短いプログラムサイズの可能性を模索している。そしてそれにも関わらず、審美感はサーキットベンダーや前衛美術家より伝統的です。小さなソフトシンセをどれくらいハックするかは、結果がどのくらいイタロ・ディスコのような"real, big music"に似ているかによって決めている。
4キロバイトサイズのソフトシンセは依然としてよく設計されている。彼らはしばしば音楽イベントの収められたシーケンスによって制御される、アナログシンセサイザーの構造をシミュレートするためにタイトなコードを使用する。しかし、256バイトは新しく4Kになってきているように(訳注：デモシーンは少しでもサイズを小さくするブームがあるんだと)、256バイトのサイズでまともな音楽を再生することがこれまで以上に求められている。それは、このサイズのクラスでも構成的なアプローチの可能性がまだ残されていることをしめしていて - 例えば、少ししかメモリが残っていないときに、私はVIC -20用のシンプルな128バイトのプレイヤーのコードを書く。しかしながら、多くのランダムな実験を伴ったアプローチは決まりきったハッキングよりも良い結果を与える可能性を最近の我々の発見が示唆している、人々はさらなる印象的な音楽の式を見つけるために競争している。おそらく、これらすべて他のどこでもないデモシーンから出てこなければならなかった何かだった。
私が特にこの"ムーブメント"で気にいっていることは、彼らが発見したソースコードを人々と共有し、他の人の努力の上に自身の実験を基礎づけ、即座に実践的な共同作業に向いていること。ごくわずかなプログラミング知識と、気が遠くなるような作業さえあれば、誰もがそれに参加でき新たな発見をすることができる。私はこの探査の段階が終わりに近づくまでどのくらいかかるかかわからない、しかし大きな塊（グループ）による実践的で徹底したハッキングを提唱する"Pan-Hackerムーブメント"が役立つかもしれないと思う。私は間違いなくこのようなプロジェクトを見てみたい。
これはどのくらい深淵か？
ソースコードの文字数が百を超えるコードに膨らめば、決定論的な努力から離れて、探査プロセスはこれまでにまして試行錯誤が必要だ。試行錯誤の実験者は、しかしながら、何か大きな構成要素として使用できるような式を直感的感覚で徐々に開発しているようだ。おそらく、将来のある時点で、誰かがなぜ、どのように我々のアルゴリズムが動作するのか説明する啓発的な数学と音楽理論的解析を発表するだろう。
すでに見てきて明らかになように、このようなものがはるかにPCMオーディオを超えたコンテキストで動作する。C64のWallflowerのような、初期の8ビットの実験では、かなり盲目的にサウンドとビデオチップのレジスタに値を書き込んで、興味深い出力になるように管理していた。メディア・アーティストのカイル・マクドナルドは"グリッチ"の構造への興味を起こさせるモノクロビットマップに音の束をレンダリングしている。通常、ビットマップとしてレンダリングするのは音楽にかなり良くないように思われる、これは小さなチップチューンのようであり、さらに音は私たちの実験に似ています、それだけでなく視覚的な可能性に気づくかされて興味深い。
私は認識している、オーディオビジュアル作品を生成する文脈では、単純なビット単位の式は音楽的出力ばかりではなく、時間関数のような様々な視覚的パラメータを動かすようなソースデータを生成することができる。これにより、例えば、256バイトのデモシーン製品にとって、興味深くかつ強力で効果と音楽の間を固有に同期した様々なオーディオビジュアル構造を持つようになる。我々が実験してきた式のようにミクロとマクロ構造の両方を生成することができる、我々は、低レベルと高レベルのパラメータを同様にあつかえるかもしれない。波の振幅とピクセルの色からレイヤーの選択、カメラパス、および3次元シーンの構築へ。今のところ、誰かがこれらのパラメータ実験を拡張するまで、これは単なる憶測です。
これが本当に深遠なものであれば私はもう言うことはない、とにかく、我々はすでにフラクタルとカオス理論を持っている。しかし、少なくともこれは私が関わっているアートにとって素晴らしいことで、それこそまさに私にとって重要なもの。私はおそらく、ときどきオーディオビジュアルの可能性を模索し受け入れ、それについてあなたにブログで報告するだろう。
