Contents menu
※この記事は2020年6月24日に更新されました。
当サイトでおすすめのDAWと言えば、Ableton , Cubase , Logicなんですが。
【DAWソフト】の選び方とおすすめ
お悩みの方にそれぞれの特徴と制作目的別のオススメを筆者の経験からお届けしていきたいと思います。
DAWで打ち込みをしていると「音が鳴らない」などのトラブルは誰でも抱えると思います。
2020年になって、ようやく、ソフトウェアの自動化が進み、音が鳴らないというトラブルは少なくなってきました。
しかし、つい10年～数10年前であれば、どんなにベテランでも「音が鳴らない」というトラブルはかなりの頻度で抱えていました。
各ソフトのトラブルシューティングを探すのももちろん解決策として正しいアプローチだとは思いますが、根本的な対処思考を身に着けておくことで、各ソフトのトラブルシューティングを探すよりも早く解決できる場合が多々あります。
トラブルの際の対処法で結果的に時短にもなりますので、例えば「cubase 音 鳴らない」などの検索でたどり着いた方も、「なんだよ、トラブルシューティングじゃねーのかよ！」
と怒らずに、ちょっとこの記事を最後まで読んでみてください。
もしかすると、今日トラブルシューティングを探す時間に加えて、将来的に都度トラブルシューティングを探す時間をカットできるかもしれません。
それでは参りましょう！
デバッグの方法は共通
デバッグ（debug）
コンピュータプログラムや電気機器中のバグ・欠陥を発見および修正し、動作を仕様通りのものとするための作業である。サブシステムが密結合であると、1箇所の変更が別の箇所でのバグを作り出すので、バグの修正がより困難となる。
引用：Wikipedia
元々はコンピューターのプログラムのバグを探す際の名称でしたが、実際には広く一般的に使われています。
例えば、昔、「スーパーファミコン」時代に、ゲームが起動しないと、カセットの裏を舐める友達いませんでしたか？
あれの真意はわかりませんが、あれで起動した経験がある方もいらっしゃるんじゃないでしょうか？
あれも立派なデバッグですし、当時はよく「バグってる」っていいませんでしたか？
西日本だけかもしれません。。。（笑）
どこにバグ（問題の原因となる虫）があるかを特定し、それを取り除くという作業です。
DAWでも、このデバッグ作業は必要となってきます。
各ソフトのトラブルシューティングを探すというのは、Q&Aにて、よくあるバグ（問題点）を提案してもらって、当てはまるかどうかのチェックをしてもらっているわけで、できればそれらのチェックは自分でやった方が早い！
というわけなんです。
そして、これは、ハード、ソフト、そして、もちろん録音作業や、映像機器、はたまた日常生活にも活用できますので、是非マスターしてください。
デバッグ方法
筆者がC（言語）の勉強を始めた際に師匠から是非「デバッグの方法を覚えてください」と言っていただき、伝授していただきました。
筆者は元々音楽家でしたので、MIDIの作業は昔からやっていましたが、C（言語）の師匠が教えてくれた方法はこれまで無意識にやってきたことの体系化で、非常にわかりやすくデバッグの速度があがりました。
みなさんも無意識にやってる方多いかもしれませんが、一度ここで体系的に整理してみましょう。
ちなみにこちらがC（言語）の師匠のヤフーショップですので、興味のある方は覗いてみてください。
相当マニアックなアイテムを取り扱っているので注意にゃ！
方法：50%ずつ可能性を削っていく
まずは、最も大きな可能性の細分化。
ソフト or ハード
ここを特定するだけでバグの場所はかなり絞られます。
MIDIシステムを基本的にハードだけで組んでいる時代などからこれは共通しています。
半々で問題点を特定していく方法。
ハード時代などは例えば、音の流れ配線の回路図を見ながらバグを特定していきます。
だいたい難しく考えて時間かかった割には、ミキサートラックがミュートになってたとか、機器のチャンネルがずれていただけだったりします（笑）
それは現代では、ソフトとハードのバグの確率は半々、もしくは、ソフト寄りであると思われますので、まず、問題はソフトで起こっているのか？ハードで起こっているのか？特定していきましょう。
ハードの可能性を潰す手順
ハードのすべての電源が入っているか？
→バカバカしい！！！と思わないで一度チェックしてみてください。
・実はキーボードの電源が入っていなかった。
・キーボードの電源が何らかの理由で抜けていた。
・電源配線タップのスイッチがオフになっていた。
なんてことは結構よくあることなのです。
また、ヘッドホンアンプのボリュームだけ完全に絞っていた・・・
なんてこともよくあります。
こういう人間のイージーミスで、一生懸命トラブルシューティングや、ソフトウェアをいじくり倒すのも時間が勿体ないですよね。
ハード単体では機能しているか？
音源も併用しているような入力装置の場合は、内蔵音源を鳴らしてみて、PC(DAW)を経由せずに音が鳴るかどうかの確認をしてみてください。
オーディオインターフェイスの場合だと、例えば、iTunesやSpotifyを鳴らしてみて音が鳴るかどうか？
MIDIデータを送信してみて、データ自体は送信できているかどうか？
方法：さらに50％削っていく
例えば、iTunesやSpotifyなどの音も鳴らない場合は、ハードのバグの可能性があります。
では次に、これを細分化していくとどうなるでしょうか？
ドライバー or 機器本体
となってくるわけです。
オーディオインターフェイスは認識されているのか？
ドライバーがなんらかの理由でなくなっていないか？
PC側から音の発信はできているかどうか？
ここで機器本体の問題があった場合にさらに細分化していくことが可能です。
MIDI インターフェイス or オーディオインターフェイス
オーディオインターフェイスは死んでるけど、MIDIインターフェイスは生きているっていうことだったあります。
また、この細分化で結果がでなければ、他の細分化を検討します。
出力 or 入力
このように50％ずつ削っていくことで、自分でバグを見つけることが出来るわけです。
仮にすぐにトラブルシューティングを探したとして、各DAWソフトウェア会社は自身のソフトウェアに関するトラブルシューティングしか用意してませんので、根本解決につながらない可能性も秘めているわけです。
ソフト側の問題だった場合
ソフト側に問題があった場合は、現代だとかなり楽に解決できます。
ハードの可能性を潰せた時点で、ほぼ問題は解決したも同然。
多くの場合
・環境設定→デバイスマネージャー
オーディオインターフェイスやMIDIインターフェイスが選択されていなかった。
という問題が多いです。
他には、ドライバーのアップデートですぐに解決したり。
問題の解決方法はソフトウェアの環境設定内にあることがほとんどなので、じっくり探りながら、経験値として蓄積していきましょう。
トラブルはすぐに検索しない方がいい理由
例えば「Cubase クオンタイズ」や「Cubase オーディオ書き出し」など、特定の方法を検索するのは、時短に繋がりますし、近道になります。
しかし、ほとんどのトラブルの場合は、検索よりもこの50%ずつ可能性を削っていく方法の方が早いですし、何よりも試行錯誤した経験という、経験値として蓄積していくことができるようになります。
同じような問題が起こった場合も、過去の蓄積された経験から特定し、解決。
このプロセスが経験値を蓄積すればするほど、高速になっていきます。
例えば筆者の場合だと、何かMIDI関連のトラブルが起こった場合、過去の蓄積された経験値を元に、考えられる原因を５つ～６つ、ピックアップして、優先順位を付けて可能性を潰していくというプロセスで、ほぼ時間をかけることなく問題解決が完了しています。
この辺りは経験値の蓄積がすべてなので、トラブルが起こった場合は、トラブルシューティングを検索するよりもデバッグ方法で解決を目指してみてください。
いらつくのはめっちゃわかります。ただ、このデバッグという作業がほぼほぼMIDIシステム、また他の多くのジャンルのプログラマーの主な業務になってくるので、落ち着いて処理していきましょう。
さらにこの50％削っていく方法は、録音業務、映像機器のトラブル、家電など、どんなトラブルでも、だいたいの原因を特定していくことができますので、便利です。
もちろんC（言語）の師匠に教えてもらったデバッグの体系化方法ですので、他のプログラミングの際も、どの位置のプログラムにバグがあるのか特定するためにも最適です。
みなさんの参考になれば幸いです。