「aRts が諸君に何ができるかを聞くのではなく、 諸君が aRts に対して何ができるのか聞くのだ。;)」
多分、あなたは aRts をもっと良くするのを手伝いたいかもしれませんが、 何が必要かが分からないでしょう。おそらく、C++やQtのプログラミングスキルなどをお持ちではないでしょう。
まず、メーリングリストに入りましょう。 詳しくはhttp://linux.twc.de/artsを御覧ください。 この文書の課題リストは最新ではないかもしれません。
このプロジェクトを推進する上で重要と思われる課題をリストにまとめてみました。 もしよければ、興味を持ったタスクに挑戦して私に報告してください...
色々な種類のシンセサイズ、エフェクト、楽器について書いた(できれば図表入りの)文書、 チュートリアルがあるといいのですが。
arts の使い方を学びたい人には次のことについてのイントロダクションが必要と思われます。 少し名前を挙げてみます。
周波数のモジュレーションとは何か?
リングモジュレーションとは何か?
オシレータはどう働くか?
フィルタの役目は?
ボコーダはどうやって作成するの?
素敵なアナログサウンドを作成するには?
303, 909, mini moog のような古いスタイルのシンセサイザはどうすれば使える?
それらのことを aRts で実現するには?
文書は sgml や html など誰でも見られる形式であると良いでしょう。
文書と指向することは同じです。aRts ができるプログラムであることをみんなに示さなければなりません!
すごい音楽ができたら、私達に聴かせてください;) arts のホームページに mp3 のコレクションを作り、 それをみんなに聴かせて、aRts を使うというのはどうゆうことか判断してもらわなければなりません。
aRts は少しずつ成長していきます。 やがてほぼすべてのシンセサイザ、スタジオ装置、 エフェクトが小さな aRts モジュールで作れるようになるでしょう。
しかし、そうなると 誰かが aRts ディストリビューションに付属する標準的なストラクチャを管理しなければなりません。 それにはミキサ、イコライザ、シンセサイザ、エフェクト、コントロールパネル、 デスクトップ補助などが含まれます。 現在の emacs で重要なのが基幹部分のコードではなく付属の emacs-lisp で書かれたマクロ (書式のハイライトや dunnet dangeon などのゲーム)であるのと同じように、 エンドユーザにとっての使いやすさは大部分が aRts 付属のストラクチャセットに掛かっています。
これは非常に大きな課題ですが、同時に興味深く、取り組むに値することでしょう。
今、モジュールはおよそ30個あります。本当に使いやすくするには、50から100個必要です。 それらはカテゴリーに分け、順序良く並べ、書くようにすることが重要です。
特に大切なのは、モジュールはすべて決まった約束事に従うことです。 例えば、あるモジュールが1/fとして指定された周波数を要求し、 他のでは f になっている必要があるとしたら困ったことです。
自分でモジュールを書く能力は(C++の知識が少し必要なだけです)この課題の助けにはなりますが、 特別に必要ではありません。 まず最初の出発点は、すべてのモジュールをふるい分けられる名前による階層を作ることです。 例えば、Synth_BUS_UPLINK =>Synthesis/Busses/Uplink とか、 Synth_SHELVE_CUTOFF =>Synthesis/Filters/Shelve Cutoff のように。 モジュール名は一種の階層になり、他の階層に移すことができないとすれば良いアイディアです。 なぜなら、そうすれば階層をそのまま翻訳して国際化バージョンに入れることができるからです。
ストラクチャになっていない Synth_PLAY、Synth_MUL、 Synth_CDELAY などのモジュールもすべて階層の中に居を定めるようにしたほうが良いでしょう。
GUI とシンセサイズシステムを、 ダイナミックロードできるプラグインでランタイム中に拡張する方法を考えてみてください。 koffice2 にこの機能がありますが、使いやすいものであるかどうかは知りません。
特にシンセサイザでは、スケジューリング中のパフォーマンス低下は許されません。;)
Arts はどうやって外の世界と交信できるのでしょうか? midi イベントはどのような経路で送れるのでしょうか? オーケイ、簡単な解決策がありますが、 これは midi バスに10個の「デバイス」が繋がっているときにはよろしくありません。まだです。 とにかく、後々まで互換性を持たせるためには公の場で(適当な KDE のメーリングリストで) 議論する必要があります。
ともかく、トラッカー(voodoo tracker、soundt racker、kegtracker)、 シーケンサ(jazz、koobase、gseq、などなど)などの他のプログラムが(Cantorは別にして) midi バスをサポートし始めれば素晴らしいのですが。
追記: 私は aRts や midi バスなどを KDE プロジェクトのものにすることだけに集中している わけではありません。ただし、私にとっては KDE の GUI を書けば、動作し、 使えるものをいちばん速く作ることができます。 私はこれで早く音楽を作りたいので、デザインに2年間も掛けるつもりはありません。;)
midi バスの音声はロードの負荷が大きいと(1秒当り1000イベント)のろくなってしまいます。 これはよろしくありません。私が思うに、 この問題は、リアルタイムにではなくイベントをバスを通して渡す方法の規準があれば完全に解決します。 これは次のように動きます。
クライアントプログラムがチャンネルを開くようサーバに要求する
クライアントプログラムが最初の10秒間(タイムスタンプ付きで)イベントを投入する
クライアントプログラムがサーバに開始を通告する
サーバがイベントがもっと必要な時にクライアントプログラムに知らせる
クライアントプログラムがソングポジションをポーリングする
クライアントプログラムが必要な時にイベントをもっと入れる
複数のイベントを連続して伝達するのは一度に1個のイベントを伝達するのよりもずっと速いはずなので、 私達は CORBA に専心することができます。
他にも、イベントを TCP ソケットや UDP や IPC 共有メモリを用いて伝達する方法があります。 これらのほうが CORBA よりも速いでしょう。
他にも何かあるかもしれません...セクションmidiバス/その他を参照してください。
ここもやりがいのあるパートです。 何が起こっているかを表示する仕組みや、音声を調整するためのボタンが必要です。 KOffice から何か再利用できるものを持ってきて、 それをランタイム中にプラグインさせられる「コンポーネント」にすることもできるでしょう。
GUI は今でも動作していますが、当然ながら改善の余地がたくさんあります。
スピードを上げられるものなら何でも歓迎します。 これには実験、分析、少しの考察が必要となるでしょう。
追記: マルチ CPU サポート(SMP)は素晴らしいでしょうね。
これはモジュールの規準化(上を参照)と深く関わります。 とにかく必要です...なぜなら、かっこよくて、夢のように動作するモジュールがなかったら、 Arts には何の価値もないでしょうから。
必要なのは、(CまたはC++の)プログラムに関する少しばかりの知識だけです。 2つのサンプルストリームをミックスするモジュールや、 オーディオデータを遅らせるモジュールなどはシンプルです;)
シンセサイズはあらゆる事を達成するのに理想的な方法ではないことは間違いありません。 例えば Steinway がほしいなら多分サンプルを買って使えば良いでしょう。 aRts で AKAI のような共通フォーマットの CD を読めれば素晴らしいでしょう。 ベロシティスイッチの付属したサンプルピアノを利用できれば、 ダイアログでそれらを手で設定するよりもずっと手間が掛かりません。
ほぼ解決しました。
aRts のフローシステムがプロセス信号だけでなくイベントも処理できると良いのですが。 こうなれば、信号を移調、結合、集成、 フィルタするモジュールをそのまま midi ストリームにも使えるということになります。
個人的に、aRts が esd や kaudioserver に将来取って替われると良いと思っています。 aRts は DirectX と DirectShow、 Generator と CuBase VST/Logic オーディオシステムのミックスになるでしょう。
とにかく、他のものと統合的に動作して、 aRts が以前のオーディオサーバが処理できるタスクをすべて処理できるようにする必要があります。
次のような問題を考えてみましょう。あなたはアブストラクト・ミキサを書きたいと思いました。 ミキサにはチャンネルとエフェクトをたくさん組み込みます。 個々のチャンネルには、プリアンプとイコライザを置きます。 それから、一定量の信号は異なるエフェクトプロセッサ(ワン・ゼロエフェクトプロセッサも含まれます。 つまり、そのまま演奏するということ)を通して送られます。
aRts でアブストラクト・ミキサを書くことは可能です。 また、エフェクト(ディレイ、リバーブ、コーラスなど...)、 楽器(ピアノ、ドラムセット、弦楽器など...)も書くことができます。
そして、それらのものは一種のストラクチャデータベースに置きます。 最後に、エンドユーザがしなければならないのは次のことだけです。
シーケンスソフトウェアを起動する。
「うーむ、ミキサが欲しいな。」
リストから1つを選ぶ。
チャンネルを追加・削除するボタンを持つ。
チャンネル数を4に設定する。
エフェクト(ディレイ、リバーブ、コーラス、空エフェクトなど)をロードする。
楽器(ピアノ、ドラムセット、弦楽器)をロードする。
チャンネルに楽器を割り当てる。
ミキサでチャンネルを調整する。
エフェクトをパネルで設定する。
作曲を始める。
(0.3.1で)モジュールとして使えるストラクチャによってその一部分は解決できるでしょう。 しかし、これは本当に完璧な構想ではありません。 この問題に関して作業がいくつかすでにありますが、おそらくもっと必要でしょう。
例えば、example_mixer_simple、example_mixer_eqfx、 example_mixer_eq、example_mixer_eqfx8 などなど...があります。 考えてみてください。なぜこんなたくさん?それに、チャンネルのカウントはハードコードなのか。 特にエフェクトがもっとたくさん出来てきたら、もっとモジュール式の方法でこれを解決しましょう。
考えてみてください。
Arts は何も計算していないときには CPU パワーを消費しないようにしなければなりません。 これを達成するにはスケジューラに大きな変更を要求します。
GUI とフローサーバは実行部分をもっと共有すべきです。共通のプラグインを用いればよいでしょう。
GUI とシンセサイズサーバの CORBA による伝達はイベント数が増えてくると駄目になります。 新たな伝達のミドルウェア、例えば CPU パワーを節約できるようなものを書く必要があります。
共有メモリ、TCP を利用するのは多分よいでしょう。
Synth_WAVE_TRI は Synth_WAVE_SAW という名前にすべきです。 そして、Synth_WAVE_TRI は他のシンセサイザと同じように再実行されるようにしましょう。 例を変えてください。
Synth_WAVE_PULSE は上がり・下がり時間を設定可能な方形波にすること。 例を作りましょう。
例えば foo というストラクチャをストラクチャ foo の内部に置き、実行するとクラッシュする。
midisend を通さずに /dev/midi を => よりよいタイミングで直接読むモジュールを書くことを 考えてください。
Wave ファイルのピッチシフティング(AKAI モジュールで実行されるのと同じ。 おそらく .cc を変換する一般的なコード)。
ディレクトリストラクチャの作り直し(やりたい場合はその前に訊いてください)。 モジュールは個々に独立したものにする。
「サーバを起動します」というださいメッセージボックスの代わりに、 はじけるスクリーンローディングコードを追加すること。画像については Harald に聞いてください。
サウンドフォントサポートを賢いやり方で統合すること。例えば、コードが...
ネイティブの ALSA サポートの追加。
進行中のサンプルローディングの実行。これにより、最初のサンプル演奏時のパフォーマンスが向上する。
Interface_MIDI_NOTE を削除し、その代わりに標準ポートを置く(結局複雑である)。
ファイル名を要求する楽器はそれを入力できるコントロールパネルを用意する(結局複雑である)。
モジュールはすべて自身のファイルを持つ。(関連:ディレクトリストラクチャのクリーンアップ)
モジュールは共有ライブラリにする。
kvt が起動していないとき新しい kvt を起動しないようにする。その代わりに xterm などを起動する。
Calculate を削除し、それにかわって CalculateBlock を置く。 その後、SynthModule から Calculate を完全に削除して CalculateBlock を置く。
kdoc の導入
ヘルプボタンを押したらヘルプが出るようにする。 最も良いのは、状況に合ったヘルプページが表示されること。