スポンサーサイト

--年--月--日 --:--

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

◆ いまさらjBridgeの設定概念・流れ

2011年05月23日 19:16

自分もjBridgeを実際に使うまで概念がボンやりしてたんで、実際の使い勝手が想像出来ずに不安だった。
そんな訳で参考までに、いまさらながらjBridgeの設定概念・流れを記載です。
自分はCubaseユーザにて64bit OS+Cubaseベースの話。

■背景(2011年)
64bit OSの普及によって、4GB以上のメモリ活用が一般的になってきた。
DAWホストの64bit化は完了したと言えるけど、プラグインの64bit対応が完璧とは言えないのが2011年現在。
そこで大きな別れ道として、64bit DAWホストと32bit DAWホストのどちらを使うか?というのがある。

それぞれにメリット・デメリットがあるのが悩ましい現状。

■可能なjBridge形態
昨今の"Bridge"って言葉は32bitと64bitを繋ぐ"架け橋"って意味合い。
jBridgeがBridge可能な形態としては下記。
1. 64bit OS+64bit DAWホスト環境で32bitプラグインをBridge
2. 64bit OS+32bit DAWホスト環境で64bitプラグインをBridge
3. 64bit OS+32bit DAWホスト環境で32bitプラグインをBridge

1番はホストが64bitにて、そもそもメモリ割当上限から開放される。目的は64bit環境で32bitプラグインを正常起動させることにある。
2番や3番は32bitホストながら4GBメモリ割当上限を越えて、プラグインに独立したメモリ割当が可能となる。
今まで32bitで開発されてきたプラグインの安定性を考えるとDAWホストとプラグインを共に32bit統一を選択するメリットはデカい。

ただ自分は64bit DAWホストを選択したので、以下は64bit DAWホストの話。
64bit選択理由は、未来はどうせ64bit一択ってのと、自分が良く使うEastWest、Spectrasonics、Pianoteq、NI Kontakt辺りが64bit対応してたから。
(自分の重要プラグインAddictiveDrumsも64bit化してないが、フォーラムで32bitでも動くとあり、実際に正常稼動中)


■64bit DAWホスト+32bitプラグイン
実際にそのまま使える32bitプラグインもあるが、64bit DAWホスト環境では上手く動作しないプラグインもある。
上手く動作する場合は、今までと同様に別段なにも気にせずにそのまま利用すれば問題ない(DAWホストのデフォルトBridgeが裏で勝手にやってくれる)。

しかしながら上手く動作しない場合にjBridgeの登場となる。
jBridge以外にもVEPという選択肢もあけど、こちらは少々お高いので、自分はjBridgeにした。


■設定の概念・流れ
Bridge対象とするフォルダを選択するところから始まる。
例えば32bitプラグインをC:\Program Files(x86)\Steinberg\Pluginsに格納してるとすれば、そのフォルダを指定する。

次に詳細設定で、"プラグインごとに個別確認"か"フォルダ内全Bridge実行"かを選択できる。

ここで各個人の好みというか、ファイル管理の志向で出てくる。

自分の場合は"プラグインごとに個別確認"が面倒なので"フォルダ内全Bridge実行"で行きたいのだが、32bitプラグイン全てをBridgeしたい訳ではない。
正常稼動するものはjBridgeを経由したいくない。
そこで32bitプラグインでBridgeするフォルダとしないフォルダを分けている(ディレクトリやフォルダ名称は適当に任意で問題なし)。
C:\Program Files(x86)\Steinberg\Plugins\jbridge_on
C:\Program Files(x86)\Steinberg\Plugins\jbridge_off
この様にフォルダを分けた上でBridgeするフォルダは"フォルダ内全Bridge実行"を適用してる。

ちなみに"プラグインごとに個別確認"とすると、各プラグインごとにBridgeする・しないを確認される形となる。
例えば20プラグインあるなら20回のYES・NOを聞かれるので、ちょい面倒。
まあフォルダ分割案も管理が面倒になるので、どっちもどっちかな・・・。

jBridgeを実行するとBridgeコンバートされたプラグイン実体(.dll)が新たに生成されるので、このコンバート.dllの格納場所を指定する。
jBridgeの推奨としては、「元ファイルとコンバートファイルを同居させるな」とあるので、自分の場合は64bitディレクトリにコンバート用の新フォルダを別途作った上で指定してます。
C:\Program Files\Steinberg\Plugins\jbridge_convert(ディレクトリ、フォルダ名称は任意で適当に)

そしてこのコンバート.dll格納フォルダをDAWホストで読み込ませる(当然Bridgeコンバート前の元フォルダはDAWホスト側で読み込ませない)。

まあ長々と書いてみたが、要約すると下記の流れだ。
1. jBridgeを起動
2. Bridge対象フォルダを指定
3. "個別"か"全て"かを選択
4. コンバート先フォルダを指定
5. jBridgeを実行
6. 完了

後はDAWホスト側で読み込みプラグインのフォルダ指定でコンバート先ファルダを指定すれば完了。
一回設定が終われば、DAWホストを立ち上げる度に何かしら操作する必要はない。


■近い未来の予測
大手プラグインメーカーの64bit版への以降は今年(2011年)中に終わるのではと推測。
これで晴れて全システムを64bit化出来る!ってなれば良いが、そうとも言えないのが悩ましい。

大手以外のメーカーやFreeプラグインでディスコンになったものは未来永劫64bit版がリリースされることは無いだろう。
これらのディスコンプラグインを使わなければ一見落着だけど、既存プロジェクトとの互換性など考えると、やっぱり使える環境は保持したい。

勝手な推測だけど、SteinbergのようにVST規格の元締としては、VST規格をブラッシュアップしていく必要がある。
現にVST3.XのExpressionのような新機能も規格化されている。
そして新しい機能を盛り込むには、ある程度レガシー規格を切り捨てざる得ない。
実際にCubaseはVST3.0以下は正式対応にしてない(実際には動くけど)。

このような推進役としてはVST3.X普及のためにも、ディスコンVST2.XのBridgeに力を入れるのは趣旨に反するんだろうね。
逆に「サードパーティは早く64bit、VST3.Xに移行しましょう!」の旗振り役ということ。

64bit、VST3.Xへの移行はユーザにもメリットがデカいんだけど、同時レガシーも使いたいというジレンマが残るんですね・・・。
VST2.X(特に2.4以下)のディスコンプラグインを気に入ったら最後、何かしらのサードパーティのBridgeは使い続ける必要がありそうな予感。
スポンサーサイト

◆ Echo Gina3G:REC時のモニターあれこれ

2011年05月12日 04:03

Win7に移行してから、Gina3Gのドライバーを64bit版(8.5)に更新。
あらま~、基本機能は同じながらGUIが変わってヤル気がでる感じ!
ということでREC時のモニター設定について、Win7移行後に再度あれこれ試してみたのを自メモ代わりに。

Gina3Gというより、自分のDAWホスト(Cubase)の設定の話ではある。

Gina3G 64bit Driver 8.5


■WET(掛録り)
これの典型例はギターのアンシミュ掛録りだけど、そこで問題になるがレイテンシー。
レイテンシー詰めまくるとノイズ&不安定の元になるから気が乗らないので、やっぱりダイレクトモニタリングの方が好き。

下記のやり方で良い感じのダイレクトモニタリングになった。

・Cubaseデバイス設定
ダイレクトモニタリングOFF ←これ重要

・DAW 入力チャンネル設定
入力チャンネルに掛録りエフェクトをインサート(アンシミュ等)

・DAW RECトラック設定
トラックの【モニタリング】ボタンをON(オレンジ色へ)

デメリットは【モニタリング】のON・OFF操作が煩雑になる点だけど、これはショートカット設定で多少はマシになる。
こうなってくるとレイテンシーも詰める必要ないから安定するし、PODxtとかの接続が面倒になってくるからソフトオンリーになる。


■DRY(素録り)
歌録りなんかでは、やっぱリバーブをモニターに戻したくなる。
コンプなんかのダイナミクス系は上記のやり方で掛録り設定した上で、モニターのみのエフェクト設定を試してみた。

・Cubaseデバイス設定
ダイレクトモニタリングOFF

・DAW 入力チャンネル設定
掛録りエフェクト以外はインサートしない。

・FXチャンネル設定
FXチャンネルにモニター用エフェクトをインサート(リバーブ等)

・DAW RECトラック設定
トラックの【モニタリング】ボタンをON(オレンジ色へ)
FXチャンネルにセンドを送る

これで心地良く歌えることになる。


■DRY(素録り)だけどモニターは完全WET
自分ではあまりやらないケースだけど、ギターで生音だけ録音しておいて、後からアンシミュを変更したときなんかの設定。

・DAW RECトラック設定
トラックの【モニタリング】ボタンをON(オレンジ色へ)
FXチャンネルにセンドをMAXで送る
センドをプリフェーダーにする
トラックのレベルを最小∞にする

・その他設定
上記と同じ

◆ DAW 64bitの憂鬱(いや、32bitの憂鬱か)

2011年05月06日 22:43

何とか64bit OSに移行できたわけだが、PCを起動するごとに細かい気付きがあって、OSやアプリのプチ設定。
やはり完全な互換性を保ったままのOSの移行は難しいもんだ。

そして今日も新たな微妙な問題発生。

Freeのプラグインで規格がVST2.3のものはjbridge経由で使っているんだけど、簡単なテストでは問題なかった。
ただよくよく聴くと、音が変わってるじゃないか…。

原因はどうやらプラグインのパラメータ編集内容が上手く読み込まれないことのようだ。
DAWホスト(Cubase)を立ち上げる度に、編集内容がデフォルトに戻ってしまってる(プリセット選択は読み込まれるけど)。

それは困るということで、VST2.3をjbridgeを経由せずに立ち上げてみると、今度はちゃんと編集内容が読み込まれた。
まあこれでOKっちゃOKなんだけど、今度はDAWホストを終了する度に「VSTBridgeは動作を停止しました」っていうアラートPOPUPが立ち上がる。
毎回アラートが出るってのも何か精神衛生上良くない。

今回は発覚したFreeプラグイン一つだけの確認だったけど、これをFreeモノ全てで確認するってのは憂鬱だな。

そもそも動作対象外の32bit VST2.3 Freeプラグインを64bit環境で完全動作さようってのが間違いであるんだがね。
まだまだOS&DAWホスト&プラグインのプチ調整は続く。

◆ 初めての自作PC Vol.7 『ついに完了』

2011年05月04日 03:48

XP 32bitからWindows7 64bitへの移行もついに完了。
超オタクなGWのPC漬け生活。

DAWホストを32bitと64bitのどちらで行こうか迷ったけど、未来は64bitに集約すると思い、64bitを選択。
Cubaseは32bitも共存インストールが可能だけど、ホストを状況によって使い分けるのもそれはそれで面倒そうなんで、64bit一本でGO。

■ここでおさらい、64bitの基礎知識
64bit OSには2種類のProgram Files用フォルダが用意されている。
・C:\Program Files
・C:\Program Files (x86)

(x86)ってのは旧システムの名残で、要は32bitアプリはこっちの(x86)にインストールして、64bitアプリは通常のProgram Filesにインストールする。
インストール時にシステムが自動判別するので、実際はあまり気にする必要はない。

さて手持ちの64bitプラグインはそのまま動くから問題無しとして、32bitプラグインの動作確認。

■xln Addictive Drums
現時点(2011年5月)で64bitはベータ版のみのリリースなので、32bit版をインストール。
これは優秀で特別処理しなくてもCubaseデフォルトで正常稼動!

■NI KORE PLAYER
これは32bit版しかリリースされてないようだけど、こちらも優秀。
Cubaseデフォルトで正常稼動!

■IK Multimedia
T-Racksシリーズを多用してるんだけど、T-Racksは32bit版しかリリースされてない。
多分64bit版はリリースされない予感。
こちらは優秀ではなく、OKラインって感じ。
Cubaseデフォルトで正常稼動するんだけど、1.5倍増しでちょい重くなった印象。
とりあえず動くのでjbridgeは経由してないないけど、ちょっと様子見かな。

■Arturia Analog Factory
さて問題児登場。
自分は2.0SE版と2.5版を持ってるんだが、XP 32bit時代からこの二つが共存しない。
Artuiraは共存可能と謳ってるけど、結果はNG。
Windows7環境でも色々なパターンを試してみたけど、結果無理だった。
もうこれは64bitがどうのって話でもなくて、メーカーの怠慢&技術不足。
しょうがいないから今までのプロジェクト互換性を考えてSE版を選択。
ArturiaはCubaseデフォルトだと正常稼動しないので、jbridgeを経由にて解決。
共存可否とブリッジの試行錯誤だけで4時間ぐらいかかったわ…。

■Free VST2.4以下
自分は結構Freeものも使うんだけど、VST2.4以下のもプラグインもjbridge経由で正常稼動。
これらは初めからjbridgeを経由させたので、Cubaseデフォルトだとどうなるかは未検証。


Intelチップセットの不良回収から始まって、マザボ不良を経て、やっと自作PC(64bit)が完成。
ただ検証・設定に使ってたI/F(Tascam FW-1082)のWin7 64bit用ドライバーはリリースはされてて使えるは使えるんだけど、超不安定。
安定I/Fに対する購買欲が激アガリ。


最新の記事


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。