スクロールが恐ろしく重くなる

OSをクリーンインストールする時間ができたので、
OS 10.4.6を入れ直しました。
少し触った感じでは、エディット時に問題は起きなくなりました。
が、急ぎで細かい作業をしなくちゃいけないときは、
信用してるProtools LEで作業しております。
なので完全に直ったか分かりません。
それから別の動作で問題が発生しました.....。
今までやったことがない作業だったので、気づきませんでした。
それについては別に書き込みます。

翡翠さん、
重要な情報ありがとうございます。
特に、
＞単一の非常に長時間のオーディオ ファイルを多数のリージョンの分け、ファイル＞の先頭付近のリージョンと終端付近のリージョン、を同じトラック上に近接して、＞または複数のトラックの近いタイミングに、置いて再生するのは、ディスクに激し＞いヘッドシークを要求することになります、つまり元のオーディオ ファイルが断＞片化したのと同じ状況になります。
この点、大変参考になりました。
こういう状況でのエディット作業はLogic7.2にアップグレードするまでは、ディスクの断片化などを気にする事もなくプレイバックしながらアレンジウィンドウでストレスなく行えていました。確かにリージョン数が極端に多くなりすぎるとリージョンを善選択するまでにインターバルを感じましたが、現在程ではありませんでした。
けそさんと同じ状況を作るために、１度スタジオのProToolsのデータインポートを試してみようかと思います。
僕個人の勝手な解釈ですが、OSXはシステムの仕組み上仮想メモリ(swapfile)、アプリケーションが使用するキャッシュファイル、システムが作成するLogファイル、バックグラウンドで走るUnix系コマンドラインが頻繁にディスクを断片化させるような仕組みにある使用だと考えます。
再起動せず、スリープのみで長時間使用し続けた場合起動時間が長くなる事があります。
以前、少し調べた程度ですがOSXは簡単なディスクの最適化を起動時に行っているという情報をみた事があります。
これはあくまで推測でしかありませんが。。
ですので、
ぴっぴさんの御指摘されている、ディスクの断片化に対する御提案も一つの解決法として参考にさせていただきたいと思っています。
今のところ、現実的にBackup作業／システム及びソフトウェアの再インストール／Plug-Inの再認証等に掛ける時間がないので直ぐには無理ですが。。
引き続き、けそさんと僕と同じ様な状況にある方々がおられましたら、情報をよろしくお願いします。

クリーンインストールした結果、
OSXはディスクの空き容量がある程度確保されていないと、
安定した速度は望めないのかなと、
改めて個人的に思いました。
現在色々とインストールする時間がないので、
OSの入っているハードディスクの空き容量は26GB。
調子の悪いときの空き容量は4GBでした。
時間がない時は、メンテナンスのしようがないので、
segekeさん、状況お察しします。
今までやったことがない作業をしているのですが、
その際にまたしても重くなる状況に直面しました。
24bit 48kHzのモノラルオーディオトラックが16チャンネルほどあります。
それらはアナログテープから取り込んだものです。
揺れている1拍ずつ鳴っているクリックのオーディオを選択します。
ビートマッピングの「Rgnからの拍子」をクリック→ガイドリージョンのノートを演奏を「1/4ノート」を選択してOKを押して、一拍ごとのBPMを自動算出させます。
するとすべての動作が恐ろしく重くなります。
再生停止に約1秒、アレンジウィンドウで波形の拡大縮小1動作につき2秒.....。
生ドラムや、その他の楽器をビートマッピングを使用して、2拍ごと、もしくは1小節ごとに手動でBPMを算出させた場合は、動作はまったく重くなりませんでした。
Protools LEのビートディテクティブ機能を使って、クリックからBPMを1拍ごとに自動算出させても、動作の重さなどは確認できません。
また、LOGIC上でBPMを自動算出させた後、スタンダードMIDIファイルを作成して、デジタルパフォーマーにインポートしても、動作の重さなどは確認できません。
そこでデジタルパフォーマーに持っていたスタンダードMIDIファイルを、デジタルパフォーマー上で、再びスタンダードMIDIファイルとしてSAVS ASして、LOGICで開いたら（そうしないとBPM情報をうつせまんでした。うーむ）、すべての動作が恐ろしく重くなります。
ということは、LOGICは大量のテンポチェンジ情報にとても弱いのかもしれません。
他の方はいかがでしょうか......。
（これは別にトピックをたてた方がいいのかも）

クリーンインストールした結果、
OSXはディスクの空き容量がある程度確保されていないと、
安定した速度は望めないのかなと、
改めて個人的に思いました。
現在色々とインストールする時間がないので、
OSの入っているハードディスクの空き容量は26GB。
調子の悪いときの空き容量は4GBでした。
時間がない時は、メンテナンスのしようがないので、
segekeさん、状況お察しします。

今までやったことがない作業をしているのですが、
その際にまたしても重くなる状況に直面しました。
24bit 48kHzのモノラルオーディオトラックが16チャンネルほどあります。
それらはアナログテープから取り込んだものです。
揺れている1拍ずつ鳴っているクリックのオーディオを選択します。
ビートマッピングの「Rgnからの拍子」をクリック→ガイドリージョンのノートを演奏を「1/4ノート」を選択してOKを押して、一拍ごとのBPMを自動算出させます。
するとすべての動作が恐ろしく重くなります。
再生停止に約1秒、アレンジウィンドウで波形の拡大縮小1動作につき2秒.....。

生ドラムや、その他の楽器をビートマッピングを使用して、2拍ごと、もしくは1小節ごとに手動でBPMを算出させた場合は、動作はまったく重くなりませんでした。

Protools LEのビートディテクティブ機能を使って、クリックからBPMを1拍ごとに自動算出させても、動作の重さなどは確認できません。
また、LOGIC上でBPMを自動算出させた後、スタンダードMIDIファイルを作成して、デジタルパフォーマーにインポートしても、動作の重さなどは確認できません。
そこでデジタルパフォーマーに持っていったスタンダードMIDIファイルを、デジタルパフォーマー上で、再びスタンダードMIDIファイルとしてSAVS ASして、LOGICで開いたら（そうしないとBPM情報をうつせまんでした。うーむ）、すべての動作が恐ろしく重くなります。
ということは、LOGICは大量のテンポチェンジ情報にとても弱いのかもしれません。

他の方はいかがでしょうか......。

（これは別にトピックをたてた方がいいのかも）

> OSの入っているハードディスクの空き容量は26GB。調子の悪いときの空き容量は4GBでした。
デフラグが起こっているのだと思います。
ハードの限界は私には分かりませんが... OSXのvolumeで書き込み、消去をさせなければ問題は起こりません。それには大きなdataはlinkしてお使いになれば4KBで済んでしまいます。OSXのvolumeでは書き込みや消去をしませんのでデフラグは起こりにくくなりますし何時でもBestな状態で使えます。
dataが30GB位ならpartitionで分けられても使えるかも知れません。HDDで分ける云々はさておいて... ようはOSXのvolumeではAppsを入れて/var, /tmp, /vmなどに支障のない大きさなら動きます。Appsは読むだけですので増えたり減ったりはしませんしOSXはCaches, Logs, /var, /tmpの書き込みが自由に出来る大きさがあれば問題ありません。なのでHDD全体をOSXで占めるのは勿体ない。OSX volumeの必要な大きさはswapfileが幾つ出来るか/tmpやCachesなどに問題ないか経験でお分かりになるでしょうから。
dataの作業場所、保管場所を作ってlinkをshell scriptで切り替えるか手作業でlinkして保管場所と作業場所を切り替えると便利かも知れません。
またSubを作ってSubのOSXのdmgを作ったり、緊急時のOSXとして使うvolumeがあれば非常に便利だと思います。Tigerを入れてcombo入れ、必要なPro Toolsを入れて。Caches, Logs, /tmp, /varの中などの起動後に生成されるfileを消去してiDefragで解消、Disk Utilityでfree spaceを消去、OSXのdmgを作っておけば問題が起こったら復元でApple純正に戻す事が出来ますし3rd partyは復元したものに入れてお使いになれば良いと思います。
dmgをmountして復元すると直ぐに使えますし連続した大きな空きが出来ていますので自由にswapfile, tmp, Cachesなどが書き込めます。swapfileは多少離れたところに出来ますが時間が経過しないと上書きしないので仕方がありませんが再起動でswapfile, tmpは消去してくれます。ただしこのvolumeにupdateをかけるとグチャグチャになりますのでデフラグの解消をしないとなりません。 :-)

APPLE STOREに問い合わせたところ(コールセンターはバグの確認だけで2万円徴収すると譲らないので)、大量のテンポ情報で重くなるのはバグだと分かりました。取り急ぎ報告まで！

APPLE STOREに問い合わせたところ(コールセンターはバグの確認だけで2万円徴収すると譲らないので)、大量のテンポ情報で重くなるのはバグだと分かりました。
LOGICはオーディオ波形の拡大縮小をいちいち計算して行っているように感じていたのですが(他のシーケンサーはいくつ拡大した波形の画像データをキャッシュで持っているか、リアルタイム計算式が大変すぐれているのでしょう)、大量のテンポチェンジ情報によって、波形の横軸表示の再計算をリアルタイムで行っていて、なおかつその計算法がよろしくないから重いんじゃないかなーと睨んでおりましたら、仰るとおりです、とのことです。
取り急ぎ報告まで！

APPLE STOREに問い合わせたところ(コールセンターはバグの確認だけで2万円徴収すると譲らないので)、大量のテンポ情報で重くなるのはバグだと分かりました。

LOGICはオーディオ波形の拡大縮小を、リアルタイムに計算して行っているように感じていたのですが(トラックが増えると突然重くなるので。他のシーケンサーはわりと軽快に動くから、いくつ拡大した波形の画像データをキャッシュで持っているか、リアルタイム計算式が大変すぐれているのでしょう)、大量のテンポチェンジ情報を扱わせると、波形の横軸表示の再計算をリアルタイムで行って、なおかつその計算法がよろしくないから重いんじゃないかなーと睨んでおりましたら、仰るとおりです、とのことです。
取り急ぎ報告まで！

APPLE STOREに問い合わせたところ(コールセンターはバグの確認だけで2万円徴収すると譲らないので)、大量のテンポ情報で重くなるのはバグだと分かりました。

LOGICはオーディオ波形の拡大縮小を、リアルタイムに計算して行っているように感じていたのですが(トラックが増えると突然重くなるので。他のシーケンサーはわりと軽快に動くから、いくつか拡大した波形の画像データをキャッシュで持っているか、リアルタイム計算式が大変すぐれているのでしょう)、大量のテンポチェンジ情報を扱わせると、波形の横軸表示の再計算をリアルタイムで行って、なおかつその計算法がよろしくないから重いんじゃないかなーと睨んでおりましたら、仰るとおりです、とのことです。
取り急ぎ報告まで！

ふと気づいたのですが、他のシーケンサーから持ってきたオーディオファイルを扱っていて、どうにも重いときは、オーディオファイルを「ファイルを複製／変換」すると軽くなることもあります。再現性がないので確かなこととは言えませんが、一応ご参考までに。。

ぴっぴさんの大変詳しい知識に驚きました。
丁寧なお返事ありがとうございます。
大量のテンポチェンジ情報を持つと重くなるバグの一件から、
とんでもなく重くなる原因は、
どうもデフラグやキャッシュではなく、
LOGIC自身が問題のような気がしています。
ちょっと重くなるくらいなら、きっとデフラグやキャッシュのせいなのでしょう。
あくまで個人的な見解です、はい。

> ふと気づいたのですが、他のシーケンサーから持ってきたオーディオファイルを扱っていて、どうにも重いときは、オーディオファイルを「ファイルを複製／変換」すると軽くなることもあります。
これはありますね〜。
ひとくちに AIF/WAV と言っても、PCM データとしてみた場合は同一でも、ファイルに実際のサンプルデータを格納するやり方は、ソフトによってまちまちです。例えば、あるソフトはデータを１秒単位に区切って格納するし、別のソフトはそれが 0.5 秒単位、また別のソフトはデータをまったく区切らず頭から一塊で入れてたり、、、。この違いが読み出す際のパフォーマンスに影響する場合があります。
Logic で一旦「複製／変換」すると、Logic が読み出すのに得意とする方法でデータが格納し直されるので、読み出しのパフォーマンスが改善する場合があるわけです。

Active Monitorで原因がある程度は分かるかも知れませんので試したら...
processが赤字だと反応しなくなってる。
%CPUが100%に近いとCPUを食い尽くしている。
processが終了が出来なかったり衝突している。
原因としてはこんな場合があります。
3rd partyのplug-ins, utilityが問題を起こしている。
設定file (plist)に問題がある。

Activ Monitorで一応監視もしてみているんですが、何も問題ないんですよねー。
プラグインもサードパーティーのものは根こそぎ抜いたりもしてみましたが、変わらずでした。設定ファイルも削除してみましたけど、やっぱり変わらずでした。

サンプルデータ格納の仕組みをすっきり解説してくれてありがとうございます！なるほど、そういう事だったんですね。勉強になりました。
経験的にはsd2ファイルが一番壊れやすいように感じます。