長らくお待たせしました。

コーディング自体は結構前に終わっていたのだけども、機能チェックに時間が取れなくて今日やっと終了。

数値エディタとグリッドエディタを統合しました。
グリッドエディタ単体での機能も残してあります。

NowAvailable!

intでbool値は。

1か。

if ( 1==n )
の評価は出来ないと、知り合いが言う。

真偽を判断するにnが0出ないことが定義なのだから、それも正しい。

false == 0

が僕らそれぞれの真実であって、
それ以上は全くの未知である。

つまり────
trueなど評価に値しないし、そんなもの真実じゃないというわけ。


なにに支配されていますん？
自分がこうだと決めたことが真実ですか。

それを真実だと思うなら、苦しみも怖くないんでしょう。

なぜ、3秒先を楽しむ心を忘れたの。

見たいもの今は全部見られるから？

*


1秒前の過去に自責を感じ、
1分前の自分に「かっこ悪い」と駄目を押し、
1時間前の気持ちに嘘をつき、
1日前の自分は「嘘だった」と言い訳をし、
１ヵ月前の自分をうらやみ、
１年前の自分に戻りたいだなんて。


1年後の自分すら考えられないような人間が、
過去を本当に清算できるのか。

言い訳をしながら今の自分を楽しむよりも、
何故楽しいかすらわからないまま楽しむ事を忘れてる。

*

nが2だったら、君という奴は自分を保っていられるのか。

*

僕らの脳はまだ、そこを判断できるだけ
退化していないのにね。

*

コンピュータが、効率を持ち合わせて
n=2

if ( n==true )
を評価できるようになるなら
それはまた僕の見たいものだろう。

しかし、人間すらそれを謝った評価している面が実際にある。僕らがそれを評価できなくてどうする。

*

冗談はさておき、

EMIDI2の設計を考えています。
大分前にアルペジエータの話をして思ったのは、やはりモジュール結合したシステムのほうが発展性があるということです。

midiomのコアになっているのが現在のEMIDIというライブラリです。

データの連続性が設計思想であるが故、犠牲にしている面が多い。

連続であるものの長さを図るために再生こそ効率が良くとも、編集のファジーさをもっと受け入れられる設計があるとわかっている。

実は、オーディオファイルを扱うほうが、「データを配置する」という点においては負荷が低いという現実。

MIDIはそういう進化を否定したし、それこそがMIDIのよさでもあるわけで。

*

次のものは現状のものよりも使いにくくなるかもしれない。軽快さが失われるかもしれない。

再生効率と、編集効率がどっちもパフォーマンスが悪くなるかもしれない。ただ、最後まで粘りがあるシステム。

今のCPU資源をぎりぎりまで使って、

敢えて─────MIDIを扱う。

かっちょえぇ。

DAWでMIDI効率が悪いものが多いのは、
MIDIのほうが負荷が高いから。

*

部品のモジュール化。
全てのモジュールは結合する。

オーディオもチョコットLOVE。

*

実現するのは５年後くらいか。
MIDIって言葉が化石になってなきゃいいけど。

*

酔っ払ってるので責任持たんよ僕ァ。

ちょっとゴージャスに。

こういうシステムで描画する部分をゴリゴリ描いてしまうと、WindowsVistaでどうなるんだろう。

ピアノロールの描画負荷は大きいため、
描画を軽くするため最適化中。

*

数値エディタは以前と異なって、自由なサイズを持つことが出来るようになったので、最大化表示ができるように。

最大化したまま、PC98時代のように一画面で使用することができます。

数値入力にはこのほうがスタイルに合う気がする。

大分サマになってきました。

・On/Offボタンをスプリッタ部分に搭載して開閉
・Nキーによる切替え時にちゃんとフォーカスが移動
・再生エンジンのシーク速度が大幅にスピードアップ。

*

・バグレポート
　Fix: TrackView: カット操作のバグ、全般的にビュー上での編集操作がおかしい
　Fix: GridEditor: Phraseを開いているときにカーソル移動でフリーズする
　Fix: GhostNote上のみで消去を行うと変なところが消える

プリミティブ、かつ、致命的なバグが発見されました。
ご不便をおかけいたします。

こういうことにしようと思う。
こうなると、例えば楽譜ビューが必要な人とグリッドエディタと同時に開きたい人と将来的には、右のペインに表示されるものを切り替えるように出来れば、皆幸せになれると思います。

*

今日は、家にsubversion環境を作った。

そのせいか、コードをぶっ壊すことを恐れずこういう「出来上がった」と信じ込ませて手をつけたくない部分もバリバリコーディングできるようになるので、一人の製作でも便利なツールであると認識。

最近は時間が無いため、ヴァージョンアップはもうしばしかかりますこと、お伝えいたします。

結局一定期間過ぎた記事へのコメントは、こちらで確認後承認するプラグインを入れた。
トラックバックも最新のプラグインに。

*

midiom Pluginの実装を復習。
少なくとも初期段階で実装されている機能であるため、今見てみると、自由を制限してしまっている仕様になっている部分があると感じた。

しかも作りっぱなしになってしまっていて、GUI部がよろしくない。

ダイナミクス処理や、変換処理は十分に対応できるが、アルペジエータのような凝ったことをするには、拡張しなければいけないという結論に。

そこで面白いアイデアが噴出。

楽曲内に持っているフレーズデータを用いてアルペジエータを実現する機能。

この機能はプラグインで実現するよりも、数値入力部にアルペジエータコマンドを用意し、使用するフレーズや設定を行うことで、普通の打ち込みのノート情報によってアルペジエータをコントロールできるという発想。

今までのフレーズ呼び出しやクローンでも似たようなイメージを設計段階で持っていて、フレーズにキーを与えることができるようにしていたのだけども、その考え方をさらに一歩進めた形だ。

midiomなんて名称も、
MIDI + idiom という造語で、素片から音楽を作っていくという理想があった。

しかしフレーズ機能に飛びつくよりも、クローンで同トラック内で複製するほうが実用では使われる機会が多い。

そこで、アルペジエータとフレーズの連携が行えるとなると、ひょっとすると最初に描いていたものに近づくんじゃないかと思い至る。

そうそう、そういや、よくシンセに搭載されているアルペジエータに対する疑問もいつも感じていた。
シーケンサとの同期をするには結構な骨だし、あれはまさにライブ向きの機能じゃないかって。

そのアルペジエータを、みっちりシーケンサで作りこめて、しかもトータルリコールがカンペキなものであれば、それは僕の理想に近いものだ。

ここでいうトータルリコールは、曲の特定の位置から再生したときに、システム内部で別軸で動いているモジュレーションやタイマーなどの機能によって、同じように演奏されないことがあるという現象に対するものである。
演算コマンドにrandom関数を用意していないのは最初はそういう理由だったりするのだけど、特に変数の値が途中再生で計算がはしょられてしまうことを避ける意味だった。しかし、そういう不安定性を良しとする場合もあるので追加してもいいかも。

プリセットで用意されたアルペジオフレーズを使うことにも抵抗があった。自分のアイデンティティとは乖離していく感覚が強くなっていってしまうため、結局使いこなせなかった。

そんな自分の思うアルペジエータとは画するものにしたい。
実際作るとなると結構オオゴトだな…。

「またまたぁマニアックな方向に」
なんて聞こえてきそうな・・・？

<%media(20060311-command_test.mdo|sample mdoFile)%>

右図のように打ち込むと、ヴェロシティが変数によって制御されます。

この例では、60と127の間を増減を繰り返します。
常に呼び出す制御コマンドはフレーズ化しておきループされるフレーズに挟むことで、自動的に演算が行われるようになります。


足しこむ値を $1に設定。
127を超えたら　$1をマイナスの値にセット
60をきったら　$1をプラスの値にセット

これでいったりきたりする動作を実現します。

$1などをVelocityに適用するには　Velocityにカーソルを合わせて、V キーを押します。
その後、利用する変数番号を入力します( $0 )


この例ではノートの位置に挟んでしまって可読性が悪くなっていますので、実際には別トラックに分けてループを組むことによってフレーズ呼び出しも一回だけで後は延々とループさせるだけで可能でしょう。

本来プラグインなどの機能で提供すべきものであると考えましたが、プリミティブな四則演算だけでも実用性の高いものが組めるため、演算機能は搭載されました。

この例のようなモジュレーション的な使い方のほかに、
楽曲中のヴェロシティを変数で管理し、後からの修正を変数への代入(MOV)一箇所だけを変更するだけで済ますような、ただの定数としての利用方法も、かなり実用的です。

数値打ちメインの方は是非チャレンジしてみてください。

特性を作ってそのインパルス応答を作ってそれを畳み込めばフィルターは出来上がるというのはわかった。

だけど、リアルタイムにカットオフを動かすようなフィルターはどうすればいいのでしょう？
レゾナンスの実現方法もわからない。

フィルターも基本はディレイ。
遅れが大きいか小さいかが大きな違い。

なんか、直感的じゃない
理論考えた人すごいな、これ。

時間軸の頭から
周波数軸の頭にならないといけないのね。

首でも振ろうかしら…。



*

midiomのプラグインのソースを見てみると、
リアルタイムにデータを吐き出すというよりは、前もってデータを生成してしかるべきタイミングに送ってもらうよう指示する設計。

MIDIの場合はコレで理にかなっていると自分では思った。

ゴールデンウィークあたりまでに、midiom Plugin SDK公開します。（予定）

VCで作っているので、他のコンパイラで作れるかわかりません。

STLを使ってます。
DLLとのデータ共有でSTLを使うと大体メモリ関係で動かないので、データの受け渡し部分はプリミティブなリストクラスを作ってます。

基本は小節刻みのループ素材を並べて、on/offのタイミングで曲を構成する。

midiomでも、
クローン、フレーズデータにon/offのスイッチングが行えれば、素材作って適当に１００個くらいループ並べてしまえば、後はon/offで曲を構成するだけみたいな挙動が可能となるんじゃないかな、と思った。

そうすると、あまり使われていないであろう（？）フレーズ機能が日の目をみる？

休符をイチイチ挟むのは意外と面倒なので、ちょっと考察の予知あり。

昨日知り合いの方が家に来ていろいろmidiomをいじっていただいた。

シーケンサそのものに不慣れな人にとってmidiomの敷居が高くなってしまっていることを実感しました。

レコンポーザユーザーであれば、すんなり入っていける部分も多いのですが、

・一番操作に慣れていただきたいのはグリッドエディタの操作です。この操作に習熟していただくと、編集速度が一気に向上します。
・次にクローン機能です。全体的な構成を不得意とする数値入力シーケンサで、全体像を先に見据えながらの編集を可能とします。


まず、設計思想として
・何か編集作業をやりたいと思ったら、それに至る最短の道をなるべく用意している。

というのがあります。

基本的に機能は付属のヘルプに記載していますが、実例を交えて解説しなければ難しい部分もあると思いますので、こちらのトピックのコメントのほうに

・具体的にこういうことをしたいがどうすればよいか

というご質問を受け付けます。
本家のほうのTIPSを充実したいと思っております。

昨今の現状においては、ニッチな設計をしているため、最終的には「体で覚える」部分が大きいと思いますが、慣れれば勝手に指が動くようになっていきますので、是非是非「ちょっと難しそうだなぁ」と感じた方もチャレンジしてみてください。

「数値入力」タイプのシーケンサをやったことは無いが、覚えてみたい、という方が増えてくれることが、この流儀というか文化（笑）が守られることだと思っておりますので。

ええ、デカく出ました（笑）