漫画文化はマルチメディアだ

[↑一覧] [新着] [ホームページ]

落書きも駄目、全く絵が描けないという人は非常に少ない。少し絵心がある人 や、漫画やイラストを描いた経験のある人なら、結構レベルが高いこともある。

Macが絶賛され、支持されている理由の一つは、やはり「初めに MacPaint ありき」ではないかと思う。しかし、日本のパソコンでコンピュータを使った描 画ソフトがヒットしているとは思えない。この原因が絵心でないとしたら、別に 原因があるはずだ。例えば、レゾリューションや発色数が不足していて、満足で きる絵が描けない、結果を保存するためのメディアが整備されていない、など。 または、絵を描くためのソフトウェアの操作が難しくはないか。(*1)

しかし、これから多くの人が初めてパソコンを触れるきっかけとして、やはり グラフィックという要素は大きいと思う。

日本には、漫画文化という独自の文化がある。電車の中でサラリーマンが漫画 を読んでいる光景は、欧米人に言わせれば異様なのだそうだ。マンガというのは、 マルチメディアだと思う。これは静止したイラストではない。紙という最も安価 なメディア上に、イマジネーションを最大限に利用して、精神的動画を頭の中で 展開するための要素をたたき込む。コマという手法は、時間的な要素、音響効果、 特殊効果を実現している。決して、文庫本の挿し絵を見ているわけではないのだ。 これがマルチメディアでなくて、何なのだ。

従って、日本の社会では、もう何十年もの前から大勢の人が、マルチメディア に親しんでいるのである。マンガという基礎文化は、別のジャンルのマルチメデ ィアを受け入れるのに、非常に都合のよい基盤である。これに比べて、例えば欧 米はやはり文字文化である。だから、BBS は欧米のパワーが圧倒的に強い。

    *

代え歌を口ずさむ人は多い。歌詞は変えずにメロディを作りなおして歌う人と いうのは、まずいない。なぜか。文章というのは、意識する／しないは別にして、 誰でも作り方を知っている。だから、歌詞を作る手法というのは、誰でも身につ けている。が、メロディの作り方というのは、なかなか教えてもらう機会がない のではないか。あるいは、作ろうとする機会も少ないのではないか。

そこで話がかなり飛ぶが、コンピュータに作曲をさせようと試みる人が少ない 原因の一つは、プログラムも書け、作曲もできる人が少ないからではないか。も しそうだとすると、私はその少ない人々の中の一人である。このメリットが活用 できないのはもったいないような気がするが、今の所しかたない。

作曲したことのない人がメロディを自作できない場合に、作曲プログラムを作 ることが可能だろうか。これは面白い試みである。例えば、英語を全く知らない 人に英語の文芸作品を作成するプログラムを作らせてみればよい。結構、作って しまうかもしれないのだ。それに、音楽となると、適当に整った和音進行で、リ ズムもしっかりしていれば、残りは相当滅茶苦茶でも、なんとか「音楽だ」で通 せるものだ。「この音楽は間違っている」というのは、「この英文は文法的に正 しくない」と断定するより、はるかに困難だ。

しかし、既存の作曲手法に従って作曲のアルゴリズムを設計するには、作曲家 とプログラマーが密接に連絡しながら作業をすすめるか、あるいは作曲家のプロ グラマーが頑張るしかないだろう。

個人的には、現在のコンピュータ音楽はイマイチだと思っている。CGに比べて 非常に芸術的な要素は限られている。現在コンピュータ音楽と呼んでいるものの ほとんどは、単にメモリに記憶させておいたデータを元にしてシーケンサーを走 らせ、MIDI の楽器の音を順に出している単純なマシンにすぎない。アドリブを 実現したと宣伝しているソフトがないわけではないが、単に常識的な和声から適 当に乱数を取りだしたに過ぎない。これもアートと思っても構わないという人は いるが、私の概念としては、アートというのは、もっと知性的なものである。 （もちろん、CGも同様に考えれば、コンピュータが絵画を作るわけではなく、人 がインプットした手順に従った描画が行われるだけのことだから、大差はないの だが）

最近(といってもかなり前)、bit(共立出版)という雑誌に、プログラミングと絵 描きのアナロジーを論じた記事があった。これは、プログラムというものを絵画 という芸術作品に見立てた点で共感したが、私ならば、プログラミングと作曲の アナロジーの方がぴったりくる。

絵画に比べて、音楽というものは、はるかに構造的である。旋律をクロックに 従って動作するいくつかのモジュールと考えてもよい。しかも、絵に比べると、 曲に要求されるルールは、非常に言語的である。ここで私の得意な「飛躍が論理 する」式議論を用いれば、「作曲するプログラムが作れるなら、プログラムを作 るプログラムも作れるのではないか」という妄想が生まれる。すなわち、もし自 動作曲プログラムを作ることができれば、自動プログラミングが可能であること の証明になるのではないか、と思うわけだ。これは相当飛躍した発想で、自分な りにも全く説得力がないと思うが、まさか鵜呑みにする人もいないと思うので安 心している。

    *

モーツァルトが天才なのは、その曲をどのようにアレンジしても、美観が全く 損なわれない所にある。比べて、ショパンの場合には、どのようなノリで、どの 楽器のどの音色を使えば、もっともしっくりくる、という感触が明確である。つ まり、楽器を取り替えて演奏してみると、こちらの方がいい、という比較が割合 簡単だ。

ところが、モーツァルトの曲は、楽器を取り替えてみても、同じ程度に素晴ら しい出来になってしまうので、どちらがよいか断定ができないことがある。音色 と無関係に、メロディが隙なく仕上がっているからだと思う。どのような演奏に しても、ぴったり合うのは実に不思議である。例えば、見事な彫刻があるとする。 モーツァルトもショパンも、超芸術的作品には違いない。しかし、ショパンを正 面から見た時に最も感動を与えるような彫刻に例えれば、モーツァルトは、どの 方向から眺めても息をのむような完成度を持っていて、しかも見る角度によって 異なった輝きの美しさを見せる。これは、実際にアレンジしてみないと、実感と してわからないと思うが。

とりあえず、プログラムも芸術の域に達するには、どこから見てもよくできて いる、と言われたいものであるが…。

    *

こういう事は、変更点のドキュメントに書いておいて欲しいというのは、望み すぎなのだろうか。

しかし、症状は確かに改善されたようだが、今度は文字化けのパターンが変に なった。今までは、入力に失敗したら、その文字が FEP をすり抜けるだけですん でいたが、今や、後の数文字が半角ずれるらしく、なだれのように化けることが ある。発生率が減ったために、全体としては改善かもしれないが、現象としては 改善かどうかよくわからない。

DynaBook の右シフトキーも、仮名入力の時に「ろ」になるのではなく、ちゃん とシフトの動作になるように変更したので、ひとまずワープロとして使うには非 常に快適なマシンになった。半年以上も使っているので、「っ」の入力を左手だ けで行う癖も付いていたのだが、これはアッという間に矯正され、ちゃんと右手 でシフトを押しながら左手の小指で「っ」を入力するようになった。

    *

本件については、私は疲れた。もはや一言も説明する力がない。何が起きたの かは全面的に皆さんの想像におまかせする。(*2)

補足

(*2) 簡単に事件の概要を紹介すると、こうである。

昔、NIFTY-ServeではXMODEMが唯一のバイナリ転送プロトコルだった。XMODEMは、 128の倍数のサイズのデータしか転送できない特徴がある。割りきれないサイズ の場合は、最後のブロックにパッドを埋めて、サイズを調整する。^Zというコー ドがこれに割り当てられる。

さて、ニフティは、テキストのサイズが常に128の倍数になるのを嫌ったらしく、 サイズの表示は最後のブロックのPAD、つまりデータの最後にある^Zを除いたも のを表示することにした。これはこれでよい。問題は、バイナリのデータも 同様に処理したということである。

バイナリのデータの場合は、最後に^Zがあっても、それは不要なデータとは限 らない。XMODEMを使ってデータを転送したために追加されたのか、元からあっ たデータなのか、判断できないのである。だから、バイナリの場合には受け取 ったデータのサイズをそのまま(つまり128の倍数で)表示するように、私はニフ ティに要求した。しかし、これは却下された。理由は分からない。私には理解 できない理由があったのだろう。

さて、その後、B Plus ProtocolがNIFTY-Serveで使えるようになった。このプ ロトコルはデータサイズも情報としてやりとりするので、1バイトの単位でデー タを正しく転送することができるのである。

B+をインプリメントするにあたり、ニフティのエンジニアは、データのサイズ としてNIFTY-Serveが表示するバイト数、すなわち、データの最後にある^Zを 取り除いたサイズを使って、きっちりそれだけをB+でやりとりするようにシス テムを設計した。その結果、あるデータは、B+でダウンロードしてもアーカイ ブから復元できないという障害が発生した。これに対してニフティは「そのよ うなデータはXMODEMで受信してください」とアナウンスした。

    COMPUTING AT CHAOS RUINS -111-
    1990-03-28, NIFTY-Serve FPROG mes(5)-234
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1990, 1996