スポンサーサイト

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

上記の広告は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は使い続ける必要がありそうな予感。
スポンサーサイト


最新の記事


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