CZP-1のご紹介

CZP-1のご紹介

とても意外な方法で話を切り出すことになりますが、ウェブページ上で完結する楽器として、phase distortion synthesis(フェーズ・ディストーション合成)をソフトウェアで実装したCZP-1をご紹介します。

CZP-1を使えば、こんなことができます…

  1. 心地よい音楽を作る
  2. 耳障りな音を出す(おまけ:スマートフォンでも可能)
  3. ジャンルを象徴するサウンド、理想的にはベース音を作り上げる
  4. ウェブを通じて友人とサウンドを共有する

…その他、思いつくことは何でも可能です。

“Phase Distortion Synthesis”は、Casioが1980年代初頭に考案し、CZ-101などの製品に採用した音響生成プロセスです。私はCZシリーズのシンセサイザーに意図的に近づいたことすらありませんが、フェーズ・ディストーション・シンセをずっと触ってみたいと思っていました。では、2026年の開発者はどうするか? 当然、エージェントを使って作るに限ります。

いいえ、これは一度きりの「雰囲気重視のコーディング(vibe coding)」ではありません。そうしてしまうと、音は正しく聞こえませんし、UIもひどいものになりますが、驚くほど遠くまで進むことができます。こうした開発における課題は、いかにして他の人が使える状態にし、完成させるかという点にあります。

演奏方法

web pageにアクセスして、音を鳴らしてみてください。その後、鍵盤に触れるか、コンピュータのキーボードを使って音を奏でることができます。

もし音が聞こえない場合は、音量が下がっているか、スマートフォンがサイレントモードになっている可能性があります。

サウンドはLibraryパネル内のバンク(サウンドのグループ)とプログラム(個々のサウンド)に整理されています。既存の「Factory Presets」バンクが選択されているはずで、そこにある様々なサウンドからそのポテンシャルを感じ取ることができます。

リンクで共有

クールなサウンドが出来上がり、それを友人も使えるようにしたい…問題ありません! あなた独自のサウンドを含むCZP-1へのウェブリンクを送信できます。こちらに以前作成したものがあります。

お好みのメッセンジャーにコピー&ペーストしたり、ドキュメントに保存したり、何でも構いません。サウンドのデータは実際のリンク内に含まれており、サーバーには何も保存されていません。

他にできることは?

MIDIに慣れている人なら、MIDIサポートは十分に簡単でしょう。これにより外部キーボードの使用やシーケンサーからの制御が可能になります。ペダルとホイールのサポートも通常のコントローラーにマッピングされています。エクスプレッション・ペダルは、プログラムのベロシティに反応する部分に影響を与えます。

その他の詳細については、CZP-1のManualを確認してください。

理由と方法

長年にわたり、いくつかのオーディオプロジェクトを試みては断念してきた経験から、プログラミングの中でも最も困難な分野の一つだと考えていました。現在のエージェント・プログラミングの流行をテストするには、うってつけの題材です。

私の作業プロセスには、様々なエージェントを互いにぶつけ合わせる工程が含まれます(少なくともClaude Code、DeepSeek in Pi、Codexが使用されました)。どういうわけか、彼らには互いに排他的な盲点があるようで、それによって単独で行うよりもはるかに成功した結果へと反復的に近づくことができます。

まずはClaudeに対し、JavaScriptを使ってウェブページ上にフェーズ・ディストーション・シンセサイザーを実装するようプロンプトを出しました。その最初の試みは驚くべきもので、ブラウザの自動化を使用して、どこからか持ってきた参照オーディオとオーディオ出力を比較しようとまでしたのです。問題は、音が正しくなかったこと、パラメータが誤解されていたこと、そしてユーザーインターフェースがひどかったことです。しかし、Claudeが捏造した信じられないほどデタラメなプリセットを含め、実際にある程度は機能していました。

その結果、Claudeが書いたオーディオエンジンに関するコメントを添えてDeepSeekに投げ直すと、DeepSeekは大量のリサーチを行い、基本波形の様々な側面が間違っていることや、ミキシング関数が間違っていることなどを突き止め、修正のためのパスを完了させました。

このやり取りは約一週間にわたって続き、彼らはフェーズ・ディストーション合成の実装という主題に関するあらゆる情報源を段階的に掘り下げ、どちらのエージェントも単独では意味のある改善ができないような、極めて完成度の高い状態へと反復的に近づいていきました。

これが、現在の、ごくわずかな非常に具体的な介入のみで動作するオーディオエンジンへとつながりました。

しかし、ユーザーインターフェースや、ポリフォニー(複数の音を同時に奏でる能力)、モジュレーション、ポルタメントによるレガート・スライディングといった、膨大なユーザー向け機能が残っています。これらはすべて、必要に応じて個別に話し合い、設計し、実装し、デバッグしなければなりません。そのどれもが自動的だったわけではなく、ポリフォニーのためのボイスのラウンドロビン割り当てのような正確なアルゴリズムを知り、まさにそれをプロンプトで指示することが、機能を完成させるために必要でした。

そこから得られた教訓は?

大きな教訓は以下の通りです:

    1. 低レイヤー作業の「難しい」部分は、もはや難しくなくなっていました。恐ろしいほどに。
    1. 実用的なシンセサイザーを作るための、曖昧で未指定なギャップ(仕様の不備)を埋める「面倒な」部分と、ウェブベースのUIを真に受け入れられる状態にする作業は、依然として面倒であり、「難しい」部分よりもはるかに能動的な監視を必要とします。
    1. LLMにマニュアルを作成させたことで、ユーザーインターフェースにおけるいくつかの驚くべき問題が露呈しました。
    1. 複数の異なるプロバイダーのモデルを使用することで、コードの品質が劇的に向上します。
    1. 正しいデザインパターン、データ構造、アルゴリズムを知っておき、それらを名前で指定する必要があります。さもないと、90%はできているものの、完全には適合しない間違ったものを強引に作り上げられてしまいます。

もしもう一度これを行うなら、UIの作業が始まる瞬間からマニュアル作成を進めます。概念的な一貫性を維持するために、それが有用なポイントであることが証明されたからです。

低レイヤー作業の状況がいかに異常であるかを強調するために、この作業中に驚いたこととして、テストの一環でLuduxiaで行ったウェブゲームを、独自の書き下ろしWebGL2レンダラーからWebGPUへ移植することを決めました。これはiOS Safariなどの影響で先延ばしにしていたタスクでした。これはエージェントの支援を受けて完了し、かなり余裕のある24時間以内にデプロイされました。WebGLやWebGPUに詳しい人ほど、これは衝撃的なことです。(CZP-1の作業の一環として、Luduxiaのビルドシステム自体もエージェントによって移植されており、それがシンセの最終的なビルドを行っています)。

私たちは、低レイヤーの知識が設計目的には有用であるものの、実装に関しては機械に圧倒される新しい時代に生きています。その傾向に抗うことは、単に苦痛への道となりますが、それは多くの人々を驚かせることになるでしょう。

ちょっと待って? これがIoT(モノのインターネット)と何の関係があるの?

80年代のシンセサイザーからは、ベンダー間のMIDI相互運用性、極めて少ないメモリと比較的少ない計算資源で興味深いサウンドを表現・生成できる能力、そして、ユーザーが目標達成や楽しさのために必要であれば、複雑で難解なものであっても学習してくれるという信頼など、多くの素晴らしいインスピレーションを得ることができます。これについては、また別の機会にお話しできればと思います。