作成者別アーカイブ: MoaiApps

LinuxでBitwig – DTM環境の構築


DTMの思い出

かつてDTMというと、PCにmidiシーケンサソフトを導入して、midi機器やオーディオデバイス、レコーダーなど、いろいろと接続する必要があり、ケーブルまみれになるのが当たり前でした。また、様々なハードウェアへの投資が必要となるため初期費用も高額になりがちでしたし、設置スペースも必要でした。

筆者はアマチュアかつ貧乏だったので、いくつかのシンセサイザーと、市販の音楽カセットテープを片面4トラックにしてレコーディングするタイプの簡易なマルチトラックレコーダーだけで制作をしていました。

日々作業に明け暮れていましたが貧弱な環境のため生産性は低く、1曲つくるために1週間〜数カ月を要しました。

15年以上前の話です。

そして現代

昨今ではPC上で楽曲制作の環境が完結できるようになってきました。DAW (Digital Audio Workstation)さえあればプロクオリティの音源を制作することが可能です。PCの性能向上により、大量のシンセサイザーやオーディオデバイスを使用した演奏も、1台のパソコンのCPUでエミュレートできるようになったのです。(ただし、生楽器やボーカルのレコーディングにはマイクやオーディオインターフェイスなどの物理デバイスが必要となります)

つまり、DAWが肝となるわけです。世の中には様々なDAWが存在し、なかにはフリーソフトも存在します。

Linux上で、オープンソースのフリーソフトだけでDTM環境を構築する場合、DAWとしてlmmsやArdourなどが候補に上がるでしょう。

真のギークであればこれらのDAWで環境を構築するのでしょうが、私の場合は「MacやWindowsに引けを取らない制作環境をLinux上に構築すること」が目的ですので、無理やり安く上げることは考えていません。

Linux用のプロフェッショナル向けDAW

Bitwig Studio - 20170221_01_a4_007アマチュアであっても、予算が許すのであればプロが利用するようなソフトウェアや機材を利用したいものです。門外不出の自己満足音源やネタ音源でもない限り、人前に出し、何らかの利用を想定して制作をすることを前提とするなら、可能な限りのクオリティは追求したいと考えます。

ここ数年のクロスプラットフォーム技術の進歩のおかげで、MacとWindowsに加え、Linuxでも動作するソフトウェアを開発するのが容易な時代に入っています。その最先端なクロスプラットフォーム技術を素早く取り入れてくれた新鋭のプロユースDAWが存在します。それがBitwig Studio(以下Bitwig)です。

BitwigについてはDAWソフト「Bitwig Studio」について(DTM博士)に詳しく説明されています。

BitwigのLinux版はdeb形式で配布されていますので、debian系のディストリビューションであれば動作するものと考えられます。Ubuntuパッケージ内容を見たところJavaFXでアプリケーションが構築されているようですので、ディストリビューション依存は低そうですが、公式にサポートしているUbuntuで利用するのが無難だと思います。

ちなみに筆者はLinux Mint 18 Cinnamonで問題なく利用できています。

尚、Linux版については国内の代理店ではサポートが無いようなので公式サイトから直接購入しました。

Windows用のVSTプラグインをLinuxで利用する

VSTプラグインをBitwigに導入することにより、サンプラーやシンセ音源を追加したり、オーディオエフェクタを追加することができます。VSTプラグインはフリーのものも含めたくさんのベンダーから様々なものがリリースされていて、あらゆるジャンルの楽曲制作に利用できます。

ところがVSTプラグインの大部分はWindows用であり、同時にMacにも対応しているものも多く存在しますが、Linux向けのものはごく僅かです。

しかし、wineを利用することで、かなりの数のWindows向けVSTプラグインをLinuxで動作させることが可能です。そのためにはいくつかの方法がありますが、筆者はairwaveを利用しています。airwaveでは、VSTの.dllファイルを、Linuxの.soとしてマッピングし、wineでこれを実行するよう設定することが可能です。airwave manager 1.3.3_008

筆者がいくつか試したところ、いくつかのプラグインたちがLinux上で利用できるようになりました。

Linuxのオーディオ環境

ソフトウェア

qjackとpulseaudioDAW上で作業を完結する場合、PC内蔵のサウンドカードやオーディオインターフェイスにLinux標準のALSAドライバーという組み合わせで問題ありませんが、DAWだけでなくVLCプレイヤーやブラウザなどで参考音源をチェックしながら作業したい場合はJACKオーディオサーバーを導入する必要があります。DAWがオーディオデバイスを専有してしまうため他のアプリから音が出なくなるためです。JACKを使用すると、JACK非対応のものを含むすべてのアプリからのオーディオをミキシングしてひとつのデバイスから出力してくれますので、楽曲制作の環境として必須と言えるでしょう。設定がいろいろと面倒ですので、初めての方はUbuntu Studioを利用してセットアップすると楽かもしれません(試していないので推測です)。Ubuntu StudioでのJACKサウンドサーバについてはUbuntuStudioTips/Application/qjackctlをご確認ください。

ハードウェア

ボーカルのレコーディングなどを行うにあたっては、入力音質やレイテンシ(再生の遅延)が問題になりますので、オーディオインターフェイスが必須となります。シンセのインスト楽曲制作のように、外部の音を取り込む必要がない場合には無くても作業できますが、オーディオインターフェイスがあると、リアルタイムモニタ環境の品質が上がり、作業効率が上がりますので導入しておいたほうが良いと思います。

筆者は、簡易なもので十分なので PreSonus の AudioBox iOne という製品を購入しました。USB接続にて、アナログ入力2つにスピーカー及びヘッドフォンの出力端子が一つずつ付いていますので、ヘッドフォンを抜き差しすること無く両方の音をモニターすることができます。筆者はこれにBEHRINGERのダイナミックマイクを接続して自分の声をサンプラーに取り込むためにも利用しています。

出力環境への投資は必要か

作品のアウトプットはデジタルファイルですので、出力環境であるオーディオインターフェイス、スピーカーやヘッドフォンに投資せずとも作業を完結させることは可能です。DAWが書きだしたwavファイルをmp3などに変換したうえで様々な環境で再生することでサウンドのチェックができます。ただし、作業効率を考えるとアレンジやミックス、マスタリングの作業をしながらモニターできたほうが圧倒的に効率が良いので、オーディオインターフェイス経由してモニター用のスピーカーやヘッドフォンでチェックするのが良いと思います。

感想

筆者はMacやWindowsそれぞれの環境にもBitwigを導入して1曲ずつ仕上げてみましたが、サウンド再生のパフォーマンスはLinuxが最も高く、マスタリング後に近い品質のまま制作作業を行うことができます。MacとWindowsはあまり差がなく、どちらもプチプチノイズの発生が気になります。Linuxは(チューニング次第ではありますが)重たい常駐プロセスが少なく、オーディオ処理というシビアな計算処理のために多くのリソースを割けるのだと思います。

ただし、Linuxは高パフォーマンスではありますが、オーディオデバイスとJACKとPulseAudioによるデバイス・ミキシング設定がやや面倒であり、運用には慣れと技術が必要となります。モバイル環境などでデバイスの抜き差しが多い場合は、頻繁にJACKのプロセスがハングアップするため、kill -KILLのお世話になる必要があります。表面上は単に音が出なくなるだけなので原因に気づきにくいです。

Macは音量アイコンの下に出てくるデバイスを切り替えるだけで全部切り替わるので楽チンです。アレンジ作業ではトラックパッドでのスクロールも便利です。

WindowsはプラグインやDTM関係ソフトの充実度が素晴らしく、万能です。ただしオーディオ環境の設定が少々わかりづらいイメージがあります(Linuxほどでは無いですが)。

どの環境も微妙に一長一短だったりするのですが、Linuxは楽曲制作環境という観点でいうと、WindowsやMacと遜色ないと言ってよいかと思います。

筆者の環境

筆者の環境をご紹介します。

  • PC
    • ThinkPad T420 (Core i5-2520M 2.5GHz), SSD250GBx2, RAM16GB
  • OS
    • Linux Mint 18 Cinnamon Edition
  • DAW
    • Bitwig Studio 2.0
    • 外部プラグイン
      • Sample Tank 3
      • Density MkIII
      • W1 Limiter
  • midiコントローラ
    • KORG microKEY-25 (25鍵小型キーボード)
  • オーディオインターフェイス
    • PreSonus iOne
      • 家にあるスピーカーやヘッドフォンをいろいろ接続してモニタ
      • ダイナミックマイク BEHRINGER XM8500

投資金額

  • Bitwig 34,816円 (Version 1のときに購入して2.0に無料アップグレードした)
  • Sample Tank 3 SE 11,984円
  • AudioBox iOne 10,800円
  • BEHRINGER XM8500 2,138円
  • KORG microKEY-25 4,892円
  • 合計 64,630円

最後に

上記環境で筆者が制作した音源をご紹介して終わりにしたいと思います。ちなみにマイクを使った音は全部ボツになったので声は入っていません。

Mac上のIntelliJの動作が重い問題の解決


LinuxやWindows環境では問題無いのですが、MacでIntelliJ(たぶんWebStormなどJetBrain社製IDE全般)を使用して巨大プロジェクトを編集しようとすると、開発に支障をきたすほど異常に動作が遅くなる場合があります。

キャッシュの削除(File > Invalidate Caches / Restart)をしたり、参照しなくても良いファイルをExcludedに設定したりすれば多少は程度改善しますが、私の環境ではそれでもやはり遅いです。昨今のWebプロジェクトだとnode_modules配下に大量のファイルが配置される場合が多く、これをExcludedとすると劇的に改善する場合もあります。

しかし、根本的な問題は、IDEを実行しているJava VMのチューニングの問題のようです。

idea.vmoptionsを編集すればVMの設定を変更できます。

$ vi /Applications/IntelliJ\ IDEA\ 15.app/Contents/bin/idea.vmoptions

私の場合、以下のように設定することで爆速環境となりました。

-Xms128m
-Xmx4096m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=225m
-XX:+UseCodeCacheFlushing
-XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC

-XmxオプションはIDEや使用する最大ヒープ容量となります。ご利用のマシンのメモリ容量に応じて調整してください。

Android/gradle: ビルドの時にdexDebugが失敗する


IntelliJにて、Androidアプリのgradleプロジェクトを新しく作成し、いくつかの外部ライブラリを使用してビルドを試みたところ、dexDebugなるタスクが失敗して困ったのでメモしておきます。

ビルドを実行すると以下のようなエラーとなります。

ThingsToDoはモジュール名です。

“dexDebug failed”で検索するといくつか情報があるようですが状況によって対策が異なるようで、私の場合は以下の方法で解決出来ました。

原因を深く追っていないのでいい加減な対応なのかもしれませんが、ひとまずビルドは通りました。

新たな問題:あり得ない場所でNoClassDefFoundError

multi-dexを有効にした副作用のようですが、enumをswitch文で分岐する場所で上記例外が発生しました。追ってみるとStack Overflowにそれらしきトピックがあり、試してみました。

build.gradleのdependenciesに以下を追記します。

そして、Applicationクラスの派生元をMultiDexApplicationに変更します。

今度こそうまくいったようです。

Android Studio / gradle: 既存のモジュールをプロジェクトに追加する


私はIntelliJのAndroidプラグインで開発していますが、Android Studioも同様だと思います。

まず、Androidアプリのgradleプロジェクトを作成し、その後に別に作成したライブラリプロジェクトをモジュールとして追加したい場合があります。IDE上だけでは完結しないようなので手順をメモしておきます。

プロジェクト配下に、(ProjectRoot)/MoaiTools/MoaiToolsLibのような外部のgradleプロジェクトをチェックアウトしたとします。ここではMoaiToolsは事前に作成したAndroidライブラリプロジェクトです。

ProjectHierarchy

上記のMoaiToolsLibの部分が取り込みたいモジュールになります。

IDE上でFile>New>Module from Existing Sources…を選択し、MoaiToolsを取り込みます。それから、File>Project Structureにて本体アプリのDependencyに追加します。

Project_Structure

 

すると、IDE上はリンクされるのですが、Build>Make Projectなどを実行するとパッケージが存在しないなどのエラーとなります。これは、IDEの依存関係とAndroid gradleプロジェクト設定が同期されていないためです。

手動でgradleファイルも修正が必要です。

(Project Root)/settings.gradleにプロジェクトを追加します。

‘:MoaiTools:MoaiToolsLib’の部分が追加となります。パスをコロンで区切って指定します。

それから、本体アプリのbuild.gradleも修正します。

 

以上でライブラリの取り込みは完了です。

私はライブラリプロジェクトをgitのsubmoduleとして他のアプリからも参照できるようにしています。

Android: spyを使用したJUnitを実行するとabstract method not implementedと言われる


Androidの単体テストでmockitoを使用していると、spyしたオブジェクトのメソッド呼び出しでjava.lang.AbstractMethodError: abstract method not implementedというエラーが発生します。これはmockitoのバージョンを変更すると解決するようです。

build.gradleのdependencyにて以下のようにmockitoの1.9.5を使用するよう修正してテストが通ることを確認しました。

GAE+IntelliJ: 開発サーバーを起動マシン以外からアクセスできるようにする


最近AppengineアプリをIntelliJで開発しています。

Cloud EndpointsでAndroidと連携するサーバーアプリなのですが、開発環境のWiFiを使用してAndroid端末からDevサーバーにアクセスしようとするとRejectedとなってしまいます。

これは、開発サーバーのデフォルト設定がlocalhost限定でlistenしているからです。これを全IPアドレスでlistenするよう設定を変更するとWiFi経由でアセスできるようになります。

listenアドレスを変更するにはサーバーの起動オプションに–address=0.0.0.0を指定します。

以下はIntelliJの設定画面ですが、Eclipseやコマンド直接起動の場合でも応用できると思います。

Run_-_AppEngine_Dev_1_9_19

GAE: Cloud Endpointsでパスが重複すると言われる場合の対応


Google Cloud Endpointsを使用すると、簡単且つセキュアにRest APIのサーバーとクライアントを開発することができます。サーバーはApp Engine、クライアントはWeb(JavaScript)やAndroid、iOSがサポートされています。APIを中心に据えたスケーラブルでクロスプラットフォームなクラウドサービスを開発する際には非常に便利な仕組みです。

しかし、そもそも仕組みが複雑なためか、いろいろとハマりどころが出てきてしまいます。それでも自分で全てを開発する場合に比べ、圧倒的なコストダウンを実現することができますので、是非マスターしたいところです。

私の場合は、以下の点でハマりました。

クライアントIDに指定すべきものはサービスアカウントのIDだった

Androidでいうと、GoogleAccountCredential.usingAudience()に渡すクライアントIDですが、「AndroidアプリのクライアントID」を渡すと認証エラーになってしまいます。ドキュメントに書いてあるのだと思いますが、実際は「サービスアカウント」のクライアントIDを指定する必要があります。

認証情報_GAE

 

APIメソッドを色々追加したところ、Multiple methods with same rest pathと言われる

初期設定の難関をくぐり抜け、色々APIを追加していくと、そのうち上記のようなエラーに悩まされます。この場合、クライアントライブラリの構築も失敗しているような気がしますが、構築時にはエラーが出ないので、実際に接続しようとした時に気づくことになります。

@ApiMethodのnameだけでは一意にならない場合があるようで、その場合にはpathも指定してやれば解決します。(例:@ApiMethod(name = “updateState”, path = “update_state”))

なんだか面倒な感じです。使い始めたばかりなので理解が足りず何かが間違っているのかもしれませんが、今のところは上記のように回避しています。

 

mavenの.m2ディレクトリにある古いライブラリを削除する


参考: http://stackoverflow.com/questions/19310650/how-clean-old-dependencies-from-maven-repositories

mavenでプロジェクトをバリバリビルドしていると.m2ディレクトリのサイズがどんどん巨大になっていきます。.m2ディレクトリを削除して再度ビルドしてやれば必要な物だけダウンロードしなおしてくれますが、一旦削除してまたダウンロードするのもなんだかもったいない感じがします。

ここでは、最近使用していないものだけ削除する方法を紹介します。

LinuxやMacOSなどUNIX系環境のシェル上で、以下のようなコマンドを実行すると簡単に掃除できます。

上記の例では5分以上アクセスされていないpomファイルのあるライブラリを削除する記述となっています。aminのパラメータを調整すればお好みの条件で削除することが可能となります。

 

株のシストレツールを公開しました


思うところがあり、1年ほどの間、株のシステムトレーディングツールを開発していました。

http://stox.moaione.com/にて公開しています。

過去30年にわたる価格データに対して売買条件のバックテストを行うことができます。シンプルでありながら実用性の高い内容になっていると自負していますので、ぜひお試しいただけたらと思います。

 

開発者ブログでは、日々のトレーディングに利用しつつ改良を重ねる過程を実況中です。ぜひご覧ください。

 

[AWS] EC2インスタンスが起動不能になったときの対処


先日、サーバーのインスタンスタイプを変更するために、インスタンスを一旦Stopしてもう一度上げようとしたら起動不能となりました。ログを見るとディスクのマウントでエラーが起きているようです。

今回は、以下のようにして直前とまったく同じ内容のサーバーを起動しなおすことに成功しましたので、メモしておきます。

  1. 問題のインスタンスがStop状態であることを確認
  2. インスタンスを右クリックしてCreate AMIを実行する
  3. 作成されたAMIを起動して内容に問題がないことを確認する
  4. 一旦新しいインスタンスをStopして固定IPの付け替えを行う
  5. 問題のインスタンスをTerminate
  6. 新しいインスタンスをStart
以上でデータを失うことなくサービスを再開できました。