Cubase 32bitか64bitか～2011年秋～

随分更新が滞っておりますが、今年の初め頃、Cubaseの32bitと64bit、

どちらを使用するのがよいかということについて書きました。

この件で検索して見に来られる方もおられるので、

いつまでも以前の情報ではいけないと思いましたので、

簡単に現状をみてみたいと思います。

あれから9ヶ月以上経ち、状況は随分変わってきました。

5月くらいでしたか、IKのARCとT-RackS3、Amplitube3が64bit対応したのを機に

メインを64bitにしました。ARCの対応だけで、ある程度負荷が減らせたからです。 

それ以降、64bit版に移行しました。

その後Real GuitarシリーズやBFD2(public beta）も対応し、

64bit環境もかなりよい感じになってきました。

Waves、UAD-2といった主力のプラグインエフェクトがまだ未対応ですから、

CPU負荷はもちろん32bit版よりも若干増えてしまいますが、

これくらいなら、Core i7搭載PCだと問題はないと思います。

さすがにバッファー48で使うには完全対応が必要ですが、

128なら問題ないです。

やはり32bit版では曲作りをしていて、メモリー不足のために動作不安定になることが

割とありました。

ソフトシンセのメモリーはVienna Ensemble Pro(以下VEP）で

分散させることができますが、大量のVEPを起動して、

プラグインエフェクトも多用する曲作りの終盤では、

32bitでは厳しくなりがちだったのが実情です。

（実メモリー2.7GB以上で落ちます。理論値の4GBまでは使えないと思います）

64bitにしてからは、そのような心配は一切無く、安心して制作を進められます。

あとCubaseでは32bitと64bitは同一ファイルですから、

必要に応じて32bitと64bitをフレキシブルに使い分けることができます。

Cubaseのよいところは、プラグインが自動的に置き変わってくれるところです。

どういうことかというと、例えば僕の場合、64bitで使う時には

UAD-2はVST Bridge、WavesはjBridgeで使用しています。

でも、これが32bit版で起動した時には、自動的にネイティブ版のUAD、Wavesに

置き換えてくれるのです。

そして32bitでWavesやUADのパラメーターを弄った場合、

それが次に64bitで起動した時には、VST Bridge、jBridge経由のUAD,Wavesにも

きちんと反映されているのです。

これは大変ありがたいことです。

例えば制作の大半は64bitで行い、これからミックスをするという段階になったら、

ソフトシンセをすべてフリーズします。

そしてその状態で一旦セーブして64bitを終了させ、

その後そのファイルを32bitで開きます。

そうすると、ミックス時は32bitネイティブのWavesやUADを小さい負荷で

使うことができます。

また最近はミックスも64bitのままでやることが多いですが、

部分的に32bitを使う場面もあります。

例えばVocalのEditをする時にWavesのVocal Riderでざっくりオートメーションを書き、

その後詰めていくことがあるとします。

64bit版ではサイドチェインが使えないため、

その部分のエディットだけ32bitで作業します。

で、オートメーションデータを書き込んだら、セーブして終了し、

同じファイルを64bitで開きます。

すると、Vocal Riderは自動的にjBridge経由のものに置き換わり、

オートメーションデータはそのままきちんと残っているので、

ここから詰めの作業は64bitで行うことができます。

このように現時点では状況に応じて、32bitを使いつつ、

大半は64bit、という具合になっております。

Cubase6とAutomapでブルースクリーン

2011.7.25更新
Novation Automapは3.7.4でブルースクリーン問題解消しております。


2011.5.25時点での話
前回のブログでMicron C400にはMarvell SATA 6G Controller 1.0.0.1036がよいと

書きました。1034ではブルースクリーンになったと。

しかし、これは情報としてはあまり意味のないものでした。

1036にしたものの、以後もブルースクリーンは出ておりました。

ブルースクリーン！！

それまでこんなことはなかったのが、C400導入後に目立って起こり始めたので、
C400が原因だと思い込んでしまっていました。

BIOSアップデートをしたり、ドライバーを最新の1.2.0.1002にしてみたり、
改めてメモリーテストしたり、PCI-EのSATA3カードを増設してみたり等々、
考えられるあらゆることを試しました。

よくなったかと思っても一時的現象で、すぐにまた発生。

しかし、発生するのは、概ね次のような状況に限られていました。

MIDIトラック数300以上、VSTiの数40～50、グループチャンネル数20以上
VSTiのアウト数140くらい、といった大規模なテンプレートを使って制作しており、
そのプロジェクトファイルを閉じた後、Cubaseは終了させず起動させたままで、
また別の大規模なファイルを読み込んだ時、開き切る直前でブルースクリーン。
（全部の音源、トラックをガッツリ使っているわけではなくても）

で、いろいろ調べた挙句、NovationのAutomapが原因だと分かりました。

この場合Cubaseのミキサー設定などに対するAutomapです。
かなりのチャンネル数になるため、Automapがクラッシュしてしまっていたみたいです。

幸い僕にとってCubaseのミキサーなどをAutomapで弄ることは全くなかったので、
この機能が失われることに何の未練もありませんでした。
そこでCubaseのデバイス設定＞リモートデバイスのところからAutomapを削除。
これでうそのように安定するようになりました。

なお、各プラグインをラッピングして使用するのは問題ありません。
実際にいくつものプラグインをラッピングして、ノブやフェーダーで弄っております。
問題になるのはCubaseのミキサー設定などを反映するリモートデバイスのところだけです。

これが元凶だった。

しかし、なぜC400を付けてから発生したのか。
ひょっとしたらSSDが増えたことで気をよくして、テンプレートの規模を
さらに拡張してしまったのかもしれません。

いずれにしても、これで一安心。
なお、チャンネルの少ないファイルでしたら、
Automapが原因で落ちることはないかもしれません。
小規模なファイルでしたら、特に問題は発生していませんでしたから。
ある程度以上になると危険なのかもしれませんね。

Micron Real SSD C400とMarvell SATA 6G Controllerの相性について

MusicLabのRealGuitar、Strat、LPCがバージョンアップし、

待望の64bit対応を果たしましたね。

今年はどんどん64bit化が進みそうです。

年内に完全移行できればよいなあと思っています。

うちではあとBFD2、SampleTank、ARC、T-RackS3、CSR、

Waves、UADといったところでしょうか。

中でも肝はWavesとUADですね。

さて、先日Micron Real SSD C400を導入したと書きました。

非常に快適に使っておりますが、導入時は少しトラブルがありました。

このSSDはSATA6G対応ですので、現PCのマザーボードASUS P6X58D-Eの

SATA6Gポートに繋ぎました。

ただ、繋いでからブルースクリーンが発生するようになりました。

といっても、起動しないとかではなく、普通に使っていて、

なぜかCubaseを終了する時など突然ブルースクリーンになって、

「え～」と思わされるといった状況でした（ファイルはセーブされていました）

頻度的には1日に1回くらい。

で、BOISアップデートとかいろいろやりましたが、

結局根本的な原因はMarvell SATA 6G Controllerのドライバーが

最新バージョンになっていなかったことのようです。

なので、これを最新バージョン（といっても2010年3月リリースですが）にすることで、

以後全く問題なくなりました。

ドライバーってほんとに大事ですね。

更新前は1.0.0.1034でした。

※2011.7.25更新
この記事を見られる方が結構いらっしゃるので、追記で情報修正しておきます。　
実はブルースクリーンは別の機器のドライバー（Novation Automap3.7）が原因で、
MarvellのドライバーとC400との相性は1.0.0.1034でも問題ないと思います。
  現在は1.2.0.1002にしていますが、全く問題ありません。
ちなみにNovation Automapは3.7.4で完全に解決しました。

LPMの設定について

前回書いていた通り、LPMの設定についてです。

LPMはLink Power Managementの略で、簡単にいうと電源管理機能です。

HDDなどのデータ転送がない時に、低電圧状態にし、消費電力を抑えるようにしてくれます。

これが有効になっていると、具体的にどんな不具合があるかですが、

簡単にいうとフリーズ状態になってしまうのです。

僕はいまシステムディスクをSSDにしていますが、

何かの都合で作業を一時中断してPCを15分くらい何も触らないまま放置したとします。

5分くらいすると、スクリーンセーバーが動き出し、15分後にはディスプレイの電源も切れます。

そして戻ってきてマウスを動かすと、画面はすぐに復帰しますが、

その後1分ほどマウスもキーボードも全く反応しなくなってしまいます。

で、しばらくすると「あ、動き出した、なんだ完全に固まったわけではなかったのか」

と思い、作業に戻るわけです。

ネットで見かけるSSDのプチフリーズってこれなんでしょうかね？

ただ、通常連続して作業している時は全く問題ありませんし、

プチフリはJMicron602コントローラー特有の問題とも聞いているので、

そういうのとも違うんではないかとも思いますが、

いずれにしても復帰後すぐに作業できないのは困りますね。

原因はデフォルトだとLPMが有効になっているから、

しばらく何のデータ転送もない状態だと、

フリーズしたようになってしまうんではないかと思っています。

実際LPM無効化以後はそういうことは起こっていません。

なので、DAW用としては無効にしておく方がよいと思います。

電源オプションの設定でHDDをスリープしないっていうのもありますが

それだけではLPM無効化にはなっていないはずです。

では、簡単に無効化の方法を書いておきます。

これはレジストリを弄ります。

ですので、初めにお断りしておきますが、これを読んでやってみようとされる方は

くれぐれも自己責任でお願いします。

不具合が出たからと苦情を言われても、こちらでは責任が取れませんので。

レジストリエディターを起動して、次のキーを弄ります。

表示が小さいと思うので、クリックして拡大して下さい。

キーのある場所、超長い名前ですね～。それにどのPCでもこうなんでしょうか。

細かい名前はともかく大体この辺りにあると思います。

設定される方は画像をクリックして拡大してご覧下さい。

何なら画像をダウンロードしてビューアーなどでさらに拡大してください(^ ^;)

WindowsXP時代はこんなことを一々設定したことはないですので、

Windows7だからなのか、あるいはSSD固有の問題なのか。

システムディスクがHDDのWindows7を使ったことがないので、

何とも言えませんが、

問題のある人はこれが一つの解決法ということで、

ご参考になれば幸いです。

Micron Real SSD C400 512GBを導入

先日IKのAmplitube3.5が出ましたね。

ついに64bit対応ですよ！

ま、これだけではCubase64bit版への移行のきっかけにはならないのですが、

今後T-RackSやARCなど、全製品の64bit対応に期待が膨らみます。

さて、今日の本題ですが、

最近Micron Real SSD C400の512GBを買いました。

現時点では決して安いとはいえないのですが、

考えていたC300 256GBが思ったほど値段が下がらず、

たまたまC400 512GBが特価で出ていて、

それがC300 256GBの倍くらいだったので、

2台買うと2ポート使うけれど、これだと1ポートで済むではないかと前向きに考え、

先行投資ってことで買うことにしました。

画像はネットの拾い物です。写真撮る前に組み込んでしまったので。

C400といえば、最大リードが415MB/s。

現在使っているIntel X25Mが270MB/sくらいですから、

かなりの速度向上を期待していました。

しかし、ソフトシンセのライブラリー読み込みに関していうと、

モノによってはほとんど変わらないこともあります。

例えばSpectrasonicsのTrilianがそうです。

IntelのSSDの1.5倍くらいにはなるんではないかと

期待していたんですが、これはほぼ変わらず。

ひょっとしたら僕のところだけってこともあるので、

断定的なことは言えませんが、

その点では期待外れではありました。

ただ、512GB（フォーマット後は476GB）あると、

かなりのライブラリーをSSDに移すことができたので、

とても快適であることは確かです。

おそらく速度向上を図るにはRAIDを組むことでしょうね。

それでもTrilianの重いパッチを瞬時にロードというのは無理でしょうね。
数秒縮めることはできるとは思いますが、
別にロード時間を競う競技をしているわけでもないので、

いまのところ、RAIDは考えていません。

ノーマルでも十分に快適ですから、そこはRAIDを組むよりも、
容量を増やして、できる限り多くの音源をSSDに移すことに
重きを置きたいと思います。
それが結果として大きな効率化、快適さに繋がりますからね。

例えばQL Pianosっていう素晴らしいピアノ音源があるんですが、

普段は重くて使っていません。

僕の場合はIVORY2がメインです。

でも３つのマイクによる響きは絶品でここぞという時は使います。

ただ、ロード時間が半端ではないのです。

7200rpmのHDDの時はSteinwayの1マイクを読むだけで2分以上掛かりました。

しかし、C400に入れると、これが20秒で読んでくれます。

全部入れると260GBを使ってしまうので、とりあえずいまはSteinway全部と

Bosen＆YamahaはPlayerポジションのマイクのみSSDに移しました。

残りはHDD。

使用頻度低いものがまだ十分とは言えない容量のSSDの大半を占めるのは

効果的ではないですので、いまはこれで満足したいと思います。

あと今回内蔵3.5インチベイに取り付けるマウンターが届くのに時間差があったので、
その間eSATA接続の裸族の二世帯住宅2.5に入れて
データを仕込んだり、試用したりしておりました。

eSATAといえば、2月5日のブログで、これではSSDのメリットを活かせない、
7200rpmのHDDでもそれくらいのベンチマークは出るぞ、
というようなことを書き、却下したわけですが、改めて使ってみて、
そんなに悪くない、というか、結構快適だと感じました。
あの時はベンチマークだけを見て、これは駄目だなと思い、
実際の使用感を試すことはしなかったのですが、
ベンチマークだけでは分からないものです。

もちろんSSDの性能をフルには活かせません。

例えばHDDだと40秒近く掛かるTrilianのパッチ。

これが内蔵ポートに付けたSSDでは10数秒ですが、

eSATAだと20秒ちょい。倍くらい掛かってしまいます。
ただ、ランダムアクセスに優れたSSDは
eSATAでもHDDでは味わえない快適さがあります。
軽いパッチだと内蔵ポートとeSATAはほとんど変わりませんでした。

この結果を受けて、もし内蔵ポートに空きがないなら、
eSATAを使うのもありだなと、認識を新たにしました。

ほんとは今日のブログで、SSD導入の際に是非設定しておきたい

LPMの無効化について書こうかと思っていたんですが、

長くなったので、次回に回します。

Cubase6バージョンアップ

少し遅れましたが、Cubase6にバージョンアップしました。

A5サイズのコンパクトなパッケージ。製本マニュアルはクイックスタートのみ。

まだほとんど試していない状態ですので、詳細は書けませんが、

バージョンアップのメリットとしてはCPU負荷が下がること、視認性がよくなること。

少なくともこの2点は挙げられると思います。

今回はCubase5.5.3がすでに入っているところへ

Cubase6もインストールするというシチュエーションになっております。

これまで同様バージョン違いは同じOS内に同居可能です。

ただし、Cubase5が入っている場合、Cubase6の初期設定ファイルが

正しく作成されないことがあります。

その場合はCubase5の初期設定フォルダを別に場所に移動させておいて、

Cubase6を起動し、6の初期設定フォルダが作成されたのち、

Cubase5の初期設定フォルダを元の場所に戻せばよいでしょう。

初期設定ファイルの場所はWindows7では次の場所です。

C:\Users\ユーザー名\AppData\Roaming\Steinberg

この中の「Cubase5」「Cubase5_64」フォルダを別の場所に移動させておきましょう。

ただ、この場合Cubase5からの設定が自動では引き継がれませんので、

ショートカットなど各種設定でCubase5のものを引き継ぎたい場合は

面倒かもしれませんが、「Cubase5」フォルダから「Cubase6」フォルダへ

コピーしましょう。

フォルダの構造は基本的に同じですので、同じ場所にコピーすればOKです。

どの設定がどのフォルダ、ファイルなのかはマニュアル等でご確認下さい。

さて、今回はとりあえずCubase6の負荷についてだけ簡単にまとめておきます。

Cubase5.5.3で作成していたプロジェクトファイルを

単純にCubase6で開いてVSTパフォーマンスのメーター値を比較します。

VSTiは20個ほど、エフェクトはUADやWavesなどを多用、
その他マスタリング系の重めのものも使用しています。

Cubase5.5.3(32bit)、バッファー64サンプル

Cubase6.0.0(32bit)、バッファー64サンプル

厳密ではありませんが、大体同じ秒数のところで撮っていますから、

負荷の違いが分かります。劇的な差とはいえないですけれどね。

実際に走らせている感覚では軽いというのがもっと分かると思います。

ちなみに同じファイルを64bit版で読み込んで測定したのは次の通りです。

Cubase5.5.3(64bit)、バッファー128サンプル

Cubase6.0.0(64bit)、バッファー128サンプル

こちらはほぼ同じくらいですが、実際に走らせている感覚では

Cubase6の方が少し軽いと感じます。

ただ、前からも書いている通り、64bit非対応のプラグインがVST BridgeやjBridgeで

動いておりますので、その分5と6での差が出ていないといえそうです。

ちなみに32bitと同じバッファー64では再生できませんでした。

（レッドランプ点灯、バリバリノイズが入ります）

そのため128にしています。

おそらくすべて64bitネイティブのプラグインで作ったとしたら、

5と6の差は32bit版と同等の差が出るのではないかと思います。

とりあえず今回はこんなところで。

Cubaseネタばかりが続いているので、次回は他のプラグインについて書いてみたいと思います。

Cubase64bitと32bitの負荷の違いについて

SSDの新型がこれから続々と登場しますね。
すでに登場したIntel 510シリーズ、
3月登場とされているCrucial C400シリーズ、
そして4月中旬発表のIntel 320シリーズ。


僕的にはC400の256GB、512GB、
Intel 320の300GB，600GBがいくらなのかが
気になりますね。


音源のライブラリーに使用するので、
容量もそこそこ必要になります。
となると、速さとの兼ね合いでC400にする可能性が高いですかね。
あと在庫処分でC300の256GBが安ければ、それもありですね。


さて、本題ですが、Cubase5.5.2の64bitと32bitでの負荷の違い、
以前のブログでも書きましたが、今回はスクリーションショットも載せて
簡単に書いてみたいと思います。


現在作っている曲のTD前の状態で計測しています。


あと64bitは32bitで作っていたプロジェクトファイルを開いただけなので、
64bit用に最適化されているわけではありません。
といっても普通に開けば、64bit対応プラグインはそれに置き換わり、
32bitしかないものはVST Bridgeや予め仕込んでおいたjBridge版が起動します。


計測時点で64bit非対応プラグインとしては、
UAD-2が10個、Wavesが5個、IKのAmplitube3が2個、CSRとかT-RackS3が3個、
Flux:: EpureIIが2個が立ち上がっています。


ソフトシンセはまだ書き出してはいません。


VSTiのラックには16個ほど。
VEProも使っていて、そこに複数起動させたりもしているので、
実際には20数個立ち上がっていると思います。
※全部使っているわけではありません。


負荷の差として出てくるのは、主にVST BridgeやjBridgeを介したものとなります。

CPUはCore i7 980X（オーバークロックはなし）
バッファーは96サンプルにしています。
オーディオI/FはFireface800です。


まずは32bit版。

次は64bit版。

再生はノイズだらけで正常には使用できません。


ちなみにバッファーを128に上げてやると、

これだと正常に再生されました。


UAD-2なんかは本来負荷はほとんどないんですが、
jBridge介すると、やっぱり負荷が増えてしまいます。
ただ1個目はぐんと増えますが、2個目からは微増といったところです。


このようにバッファー大きめでも構わないって人だと
64bitも行けるかもしれないです。


大きめといっても5～6年前だと128で再生できれば
十分低レイテンシーといえたでしょうしね。


ただ、より低レイテンシーで安定して使いたい人には
32bitがよいかと思います。
もちろんWavesやUADなど、
64bit非対応プラグインは一切使わないという人は
積極的に64bitで行かれるとよいでしょう。



僕の場合はWaves、UAD-2、できればIKも。
これらが64bit対応してくれるまでは、
32bit+VEProで行こうと思っております。

メーカーさん、早く対応させて下さい！

システムをSSDにするにあたって

年末に新しく導入したPCはシステムをSSDにしました。

SSDは容量と値段のバランスからMLCタイプを選んでいます。

MLCは書き換えが1万回とか言われているので、

システムに採用するのはどうかなと思っていましたが、

最近はMLCタイプのSSDをシステムディスクに採用しているPCも結構見かけるし、

MacBookAirもそうですから、いいんじゃないの、と軽い気持ちで採用しました。

それに

http://botchyworld.iinaa.net/ssd.htm#spec

を拝見していますと、Intelなど信頼できるメーカーのものであれば、

そんなに寿命を気にする必要はないかなと思えます。

それに決してHDDの方がSSDより長持ちするってことも言えませんしね。

ちなみに僕が使っているのはIntel X25-M 120GBです。

フォーマット後は約111GBになります。

そこにWindows7 64bit Professional、

さらに音楽制作ソフトやら事務用ソフトやら結構な数をインストールして

現時点では空き容量53GBです。

120GB以上を選んでおけば、まず大丈夫でしょう。

あと寿命の点からも空き容量がある程度ある方が安心です。

さて、最近のSSDはそんなに寿命を気にしなくてもよいだろうと書きましたが、

それでもなるべく書き換えは減らすようにしたいものです。

精神衛生上からも。

でも神経質過ぎるのも考えもの。書き換えを減らそうとする余り、

何でもかんでもHDDに移動させていては、SSDのメリットも薄れていきますからね。

現状僕がやっているのは次のことです。

1.メールデータ、一時ファイルなど頻繁に書き換えが行われるものはHDDに移動させる。

ただし、簡単にできる範囲で。

ユーザーフォルダをすべてHDDに移動させたりはしていません。

ドキュメント、ミュージック、ダウンロードフォルダなど基本的なところだけ。

メールソフト、ブラウザ、それぞれで一時ファイルの場所とか、データ保存先は設定

できるはずなので、それは各ソフトでやっていきます。

いまやっているのはメールソフトのThunderbird、IE、Evernoteなどですね。

GoogleChromeは簡単にソフトで設定はできないみたいなので、

いまのところ、そのままです。つまりSSDにあります。

ただ、このように設定しても、試しにシステムディスクで

今日の日付で更新されたファイルを検索すると、

ぞろぞろ出てくるんですよ。

なので、この辺は実は気休め程度かとも思ったりするんですが、

それでもやらないよりはいいと思うので、という感じです。

※ユーザーフォルダを移動させると、この部分はぐんと減らせるようには思うのです。

ただ、どうも上手く行きませんでした。移動はさせられたのですが、

デスクトップの設定が初期化されてしまっていたり、

ログイン時に少し時間が掛かったり等々。多分失敗しているからでしょうが。　

2回ほど試してみましたが、駄目で、これ以上時間を掛けるわけにもいかず、

現時点では取りやめることにしました。

今後もよほど気が向かないとやらないかも。いい意味での割り切りもできました。

あと、OSが管理している一時フォルダの場所は次のようにして変更します。

現在はIドライブ（HDD）に設定しています。

2.ページングファイルはシステムディスクは「なし」にして、HDDに。

ページングファイルの容量は1024MB。

システム管理だと35GBくらいに設定しようとするんですけれど、

RAMが24GBあるから、1GBくらい設定しておけば十分らしいので。

あと初期サイズと最大サイズを同じ値にしておくと、

仮想メモリの断片化を防ぐことができるらしいので、一応そのようにしています。

3.バックアップを常にしっかり取っておいて、ディスク交換が必要になっても

スムーズに復旧できるようにしておく。

現状ではフリーのParagon Backup ＆ Recovery 2011をメインに、

OS標準の「バックアップと復元」も月一くらいで取っています。

Paragonの方はソフトのアップデートとかする前には必ず取っています。

一度バックアップを取ればあとは差分バックアップでOKです。

Paragonでは一度復元テストも行っております。

バッチリ、問題なく復元成功でした。

いくつかSSDをシステムディスクにする際の（僕なりの）ポイントを書きましたが、

なんだかんだいって、結局バックアップが一番大事かなと思います。

そしてこれはSSDに限らずパソコンを使う人すべてにとって大事ですね。