JunktraX /
+81 REASON TRAX
Rack Extensionの開発に関する情報(非公式) for Windows
※Propellerhead社および株式会社コルグは運営に関わっていません。
This webpage has Nothing to do with Propellerhead and KORG. Here is by personal developer.
※現在「です・ます調」に統一中ですが後半は「だ・である調」が混在してきます
はじめに
このページは、Rack Extensionの開発に関する個人的な備忘録というスタンスです。可能であれば、開発によって知り得た情報を公に向けて共有しようと試みる側面も併せ持っています。
Rack Extension開発に必要な知識
けっこう多岐にわたりますが以下に列挙します
[01]Rack Extensionそのもの(VSTの知識だけでは不十分です)
[02]コマンドラインでOSにアクセスするための最低限の知識
[03]デジタル信号リアルタイム処理(DSP)に関するあれこれ
[04]C/C++プログラミング言語
[05]3DCG(アニメーション含む)に関するあれこれ
[06]COLLADA 1.4.1ファイルフォーマット(XMLベース・拡張子 *.dae)
[07]Scenegraphファイルフォーマット(XMLベース・拡張子 *.sg)
[08]Materialファイルフォーマット(XMLベース・拡張子 *.library)
[09]Python 2.x(Python 3.xではない)
[10]Luaスクリプト言語
[11]音楽への好奇心(デバイス設計アイディアの源泉)
言語をひとつ習得するだけでも大変ですが、Rack Extensionの開発においては複数の言語を同時に習得していかないと成り立たないようです。マイシンセを作りたければ、やるしかありません。
最初に読むドキュメント
多くの重要なドキュメントは、SDK\Documentationフォルダにありますが、最初のステップとして適しているのは、JukeboxSDK直下にある唯一のドキュメントファイル、Jukebox SDK readme.pdfです。サンプルプロジェクトをビルドするための具体的なコマンドが記述されています。
JukeboxSDKの入手方法
Rack Extensionの開発に関する情報のシェアとして、まずは配布不可な「JukeboxSDK」の入手方法と、そこに収録されたサンプルプロジェクトのビルドに必要な開発環境の整備と動作確認までをご紹介します。
デベロッパ登録からサンプルプロジェクトビルドまでの手順
[1]フルバージョンのPropellerheads Reasonを購入しアカウントを取得します
※デモ版、機能制限バンドル版などの場合はフルバージョンにアップグレードします
[2]独自ドメインを取得し有効なファイルを設置しておきます
※デベロッパ登録フォームにデベロッパ名をリバースドメイン形式で入力する必須項目があります
※またユーザーサポート窓口としてemailアドレスも必須項目です
[3]Propellerheads公式サイトのデベロッパ登録フォームに必要事項を入力し送信します
※日本在住の日本人の場合、TINにはマイナンバーを入力します
[4]SDKなどの開発ツール群(すべて無料)をダウンロードします
※デベロッパ登録完了メールにURLが記載されています
[5]Python 2.x(無料)をインストールします
※SDKはPython 2.xで書かれており、MacにはPython 2.7.10がプリインストールされています
[6]Visual Studio 2012をインストールします
※Visual Studio Express 2012(無料)でも可です
[7]Visual Studio 2013をインストールします
※Visual Studio Community 2013(条件を満たせば無料)でも可です
※必要なコマンドプロンプトはVS2012ですが、Expressには無いCommunityの機能も両方が必要です
[8]Visual Studio 2012のコマンドプロンプトからサンプルプロジェクトをビルドします
※環境変数にPythonのPATHを通し、サンプルコードのあるディレクトリで実行します
※Windows+Pauseや、PCを右クリックからのプロパティなどでPythonのPATHを追加します
※チェンジディレクトリは「cd フルパス(+ エンター)」です
※ドライブチェンジは「ドライブレター:(+ エンター)」です
[9]Reason Recon(開発版Reason)にビルドしたREが追加されていることを確認します
※%APPDATA%\Propellerhead Software\RackExtensions_Dev
[ヒント - Tips]
Visual StudioはWindowsの環境変数で通っているPATHを認識するためコマンドプロンプトのどこにいてもpythonと入力すれば>>>と表示されPythonのプロンプトに入れますが、Pythonにはソースコードの中でPATHを指定しなければならないため、Visual Studio 2012のコマンドプロンプトではCDコマンドを使って、毎回プロジェクトのあるディレクトリの階層まで移動する必要があります。たとえばCのルートディレクトリにRack Extension開発ツール専用ディレクトリC:\RESDK\を作ってあると仮定した場合、ExamplesフォルダにあるSimpleInstrumentをビルドしようと思えばコマンドラインから次の入力が必要となります。
cd C:\RESDK\JukeboxSDK_300_38_Win\SDK\Examples\SimpleInstrument
毎回こんなものを入力していられないので、cd と入力したあとは、対象のプロジェクトフォルダをコマンドプロンプト画面にドラッグアンドドロップすれば自動的にそのパスが入力されます。Visual Studio 2012のコマンドプロンプトもタスクバーにショートカットを置くなどして素速くアクセスできるのが望ましいです。
[重要 - Important]
Rack Extensionを開発するには、
[1]C/C++
[2]DSP
について精通していることが求められます。加えてPython 2.x、Lua、Collada 1.4などの知識もです。
誰もが開発者として登録できます
EU VATやらTINやら馴染みのないワードに戸惑いましたが、個人開発者の場合ひとまずはマイナンバーさえあればクリアできます。Propellerhead社は「Register your company」と言う一方で「If you don’t have a company yet, you can put your own name in the company name field.」とも言っています。Propellerhead ShopでProductsを販売するにはスウェーデンが加盟するEUのVAT(付加価値税)への登録は必須です。Propellerhead Shopに限らず、欧州でビジネスを展開する上において、VATは必須ルールのようです。そういった中において、純粋に「Reasonでシンセを作りたい」と想う個人開発者にとって「VAT番号の取得はシンセが完成してからでも遅くない」といった敷居の低さは、とても有難いシステムです。
GUIの制作
ひと通りサンプルプロジェクトをビルドしReconでの動作確認も終えた時点で特に問題が発生していなければ、これは既にRack Extensionの開発環境が整備されているという意味です。マザーボードや45などの気になるキーワードはひとまず頭の片隅に置いて、次に「最小構成のGUI制作」に着手します。
Rack Extension GUIの復習
GUIには次の4画面(4パネル)が不可欠です
[1]Front panel
[2]Back panel
[3]Folded front panel
[4]Folded back panel
上記はすべてのデバイスタイプに共通した最も基礎的で不可欠な画面要素です。この4画面は文字通りフロントパネルとバックパネル、そしてそれぞれの折り畳まれた時の画面です。Rack Extensionを象徴するのがバックパネルの存在であり、この仕様はVSTとの決定的な違いです。また、3Dアセットを座標に配置する上でZ軸(Depth)の指定は不可欠なのですが、このあたりは3DでGUIを設計する醍醐味のひとつといえます。
SDK\Examplesフォルダに、新規フォルダを作成します。たとえばSDK\Examples\ReGUI_test1Uなど。その中に、GUI\resourcesフォルダを作成します。作成したSDK\Examples\ReGUI_test1U\GUI\resourcesフォルダに、3D GUI Part LibraryのPanelsフォルダから以下をコピペします。
[1]Panel_Front_1U
[2]Panel_Back_1U
[3]Panel_Front_Folded
[4]Panel_Back_Folded
ファイル名が同じでも気にせず上書きコピーします。SDK\Examples\ReGUI_test1U\GUI\resourcesの中には以下のフォルダがコピーされます。
geometries
materials
scenegraphs
textures
SDK\Examples\ReGUI_test1U\GUIに、拡張子*.deviceで新規ファイルを作成します。たとえばSDK\Examples\ReGUI_test1U\GUI\ReGUI_test1U.deviceなど。中身はテキストで次のように記述します。
<device>
<deviceFrontScenegraph file="Panel_Front_1U.sg"/>
<deviceFrontFoldedScenegraph file="Panel_Front_Folded.sg"/>
<deviceBackScenegraph file="Panel_Back_1U.sg"/>
<deviceBackFoldedScenegraph file="Panel_Back_Folded.sg"/>
</device>
これをBOMなしのUTF-8で保存します。保存したReGUI_test1U.deviceが、R2DToolフォルダ配下のRackExtensionDesigner.exeで表示されることを確認します。これは、すべてのデバイスタイプに共通する最小構成のGUIです。
さらに、3D GUI Part LibraryのDecorationsフォルダからTape_HorizontalフォルダとTape_VerticalフォルダもコピペしてくるとRack Extensionらしさが増します。ドラテと略されることもあるドラフティングテープですが、Reasonでは「Each device has a “tape strip” which shows the name of the device.」と表現されています。新たにコピペした3Dアセットのネーミングは、単純に「水平か垂直か」の呼び分けのようです。
Scenegraph
拡張子*.sgに記述されているのはXMLベースのファイルフォーマットScenegraphです。GUIの各パネルを親ノードにして、3Dアセットの配置を座標指定します。上述の「最小構成のGUI」では、拡張子*.deviceで3Dアセットを直接指定しましたが、複数の3Dアセットを配置していくには、土台となるScenegraphファイルの上に3Dアセットの配置を座標指定します。具体的には、scenegraphsフォルダに以下の新規ファイルを作成します。
front.sg
front_folded.sg
back.sg
back_folded.sg
中身はテキストで次のように記述します。
<scenegraph version="1.0">
<translationNode id="root">
<translation distance="0 0 0"/>
<!-- Panel -->
<scenegraphNode id="Panel">
<scenegraph file=".sg"/>
</scenegraphNode>
</translationNode>
</scenegraph>
scenegraph file=".sg"にはそれぞれのファイル名に対応した3Dアセットを
scenegraph file="Panel_Front_1U.sg"
scenegraph file="Panel_Back_1U.sg"
scenegraph file="Panel_Front_Folded.sg"
scenegraph file="Panel_Back_Folded.sg"
と記述し、BOMなしのUTF-8で保存します。この土台となるScenegraphファイルに、Tape_Horizontal.sgを追加します。具体的には、
<scenegraph version="1.0">
<translationNode id="root">
<translation distance="0 0 0"/>
<!-- Panel -->
<scenegraphNode id="Panel">
<scenegraph file="Panel_Front_1U.sg"/>
</scenegraphNode>
<!-- Device name tape strip -->
<translationNode id="Device_Name">
<translation distance="150 0 0"/>
<scenegraphNode id="Device_Name">
<scenegraph file="Tape_Horizontal.sg"/>
</scenegraphNode>
</translationNode>
</translationNode>
</scenegraph>
のように。ReGUI_test1U.deviceも次のように書き換えます。
<device>
<deviceFrontScenegraph file="front.sg"/>
<deviceFrontFoldedScenegraph file="front_folded.sg"/>
<deviceBackScenegraph file="back.sg"/>
<deviceBackFoldedScenegraph file="back_folded.sg"/>
</device>
Rack Extension DesignerをReloadします。
少しReasonらしくなりました。
(※以上かろうじて整理してみましたが以下はまだ未整理な状態であり話が前後しています)
(※以下「だ・である調」が混在してきますが今後「です・ます調」に置換予定です)
Rack Extension開発のスタート地点
まずは*.pyを読み解くところから。最初の*.pyは、その大半がPATHの指定に終始している。最も基本的なPythonモジュールもここでimportされており、最後の1行でメインモジュールを呼び出している。そのメインモジュール*.pyも最初に多くのPythonモジュールをimportしたあと、*.cppを呼び出している。大半はdef文で関数の定義に終始しており、終盤では*.luaも呼び出している。呼び出された*.cppではいくつかの*.hがincludeされており、容易にはプロジェクトの全貌が把握しかねる構造になっている。Luaはさておき、まずはPythonとC/C++について知らなければ先には進めない。
具体的には、
▼Pythonの標準コマンド
▼Pythonのモジュール
▼SDK固有のモジュール
▼ざっくりとしたC/C++の知識
まずはPythonの標準コマンドであるimportとdef文とを軽く理解しておく。importされた*.pyの中身を理解するのはあとまわし。重要なのは、そのモジュールがPython由来なのか、SDK固有なのかの把握。Python由来であればざっくりと理解しておき、SDK固有であれば、ひと通り流れを把握しておく(メインモジュールでimportされるre.pyはPython由来でありSDK固有のモジュールではない)。プロジェクトの本体は、C/C++のライブラリにある。こちらも同様に、そのライブラリがC/C++由来なのかSDK固有なのかを把握し、SDK固有の部分を熟読していく必要があるが、まずはどのようなライブラリを呼び出しているのかを眺めて全体像を把握するだけにとどめておく。
バンドや打ち込みも模倣するところから初めるように、プログラミングも同様に、サンプルコードをコピーしてリネームし、改造していくところから理解が深まる。SDKには、そのスタート地点となる素晴らしいサンプルプロジェクトがいくつか収録されている。まずはそのサンプルプロジェクトのうちのひとつをコピーしてリネームすることを一番最初の作業にするのは良い選択のひとつといえる。さらにサンプルプロジェクトと同じ階層のディレクトリにコピーすることでPATH指定を改変する手間も省け、無用なバグに惑わされずに済む。
基本的な仕様を決める
ひと通りサンプルプロジェクトをビルドして動作確認したら、いよいよ改造だが、その前に大雑把に仕様を決める。このSDKには数多くのヒントとツールとライブラリが懇切丁寧に用意されているが、最初はいたってシンプルが良い。カテゴリはユーティリティ。インストゥルメントだとオシレータやユーザーサンプルの読み込みなど何かしらの音声信号を自ら生成しなければならないが、エフェクタやユーティリティであれば、入力された信号を処理するだけで済む。エフェクタにはバイパス・オン・オフを実装しなければならないので、よりシンプルなユーティリティは一番最初に改造するのに良い選択のひとつといえる。
最初はフロントパネルは白紙で良い。バックパネルに音声入力端子と音声出力端子とがあるだけ。来た信号をそのまま出すだけのスルーボックスから着手してみる。それが成功したならフロントパネルにLEDを配置して信号の入力があれば点灯するなどのように反応させてみる。次にいよいよツマミ類。ノブでもフェーダーでもお好みに合わせて、まずは音量を制御するツマミを1個だけ実装する。このようにして、段階的にトライアンドエラーでひとつずつ地道に、このSDKで何が出来るのか可能性を探っていく。デベロッパ登録するほどのReasonのヘヴィユーザーであれば、SDKなど読まなくてもRack Extensionの可能性は既に熟知しているかもしれないが、それがどのようにして実現しているのかを知るには、SDKを熟読していく必要がある。
デジタル信号処理を理解する
Propellerheadは、Rack Extensionが64フレームで動いていることをブログなどを通して公表している。シンセサイザーにはレイテンシーの問題がつきまとう。アコースティックなピアノやギターであれば弾けば鳴るが、どんなにCPUの処理速度が向上しても、アコースティック楽器に慣れ親しんだ人が、たとえばReasonのRadical Pianoなどを弾くと、ほんの僅かではあるが違和感があるのは認めざるを得ない。たったの1000分の1秒程度の遅延にすぎないのに、その鍵盤にはハンマーと弦の代わりに基盤とケーブルが接続されている、それだけの違いなのにジャストフィット感が損なわれてしまっている。しかしそれは長年にわたってアコースティック楽器を弾き続けた経験からくる違和感にすぎず「そういうもんだ」と割り切ってしまえば、それはそれで気持ちよく演奏できる。たったの1000分の1秒である。そのくらいであれば人は慣れてしまう。
されど、1000分の1秒である。
この僅かな時間にリアルタイムで信号を処理する必要がある。Propellerheadが公表している64フレームとは、その縛りでもある。具体的には、CD音質の場合であれば1秒間に4万4100個のデータがあり、これを64個ずつ処理する。4万4100個を64個ずつなので、1秒間に689.0625回の処理であり、1回処理するのにおよそ1000分の1.45秒の猶予がある。ここにすべての想いを詰め込むのが、DSPのリアルタイム信号処理といえる。DSPについて何となくイメージが掴めたら、信号の入出力を扱う関数名をドキュメントから探し出し、SDKフォルダをその主要な関数名でGrepするなどして見つけ出し、どこで宣言され、どのように使われているのかサンプルプロジェクトなどのソースを読み解いていくことになる。ここから先は、DSPへのさらなる理解とC/C++への深い知識、PythonやLuaほか諸言語の知識に加えて2D/3Dのグラフィックデザインの知識までをも要求される茨の道を歩むことになる。
Rack Extension開発の考え方
Rack Extensionはサンドボックス環境つまりある種の監視制限の中での開発となる。OSライブラリやメモリには直接的に自由なアクセスが認められず、すべてはSDKが用意したツールの組み合わせや応用によってのみ実現可能となる。しかし、SDKの仕組みへの理解を深めようとソースコードを遡ると、最終的にはWindowsAPIなどに辿り着く。ここで立ち止まってWindowsAPIへの理解を深めれば、より深くSDKを理解することにも繋がるが、どんなにWindowsAPIを理解したところで、SDKのサンドボックス環境の外には出られない。ここは「Reasonというシステムの上で走ればOK」だと割り切って「外の世界のことは気にしない」というスタンスによる開発が、よりシンプルに結果を出せる良い選択のひとつといえる。C/C++その他各種言語の文法様式でプログラムを書き、独自の変数や関数あるいはクラスなども使うが、それらはReason言語というプログラミング言語の範囲内でプログラムする感覚ともいえる。
Rack ExtensionのGUIシステム
Rack Extensionの開発では、C/C++などのプログラミング言語とDSPへの精通に加えて、GUIに関する知識も求められる。2Dか3Dかは選択できるが、厳格にReason規格である必要があり、とてもではないが、すべてのパーツを3Dモデリングなどしていられない。しかし、Propellerheadは膨大な量のパーツ群をライブラリとして提供しており、GUI専用のチュートリアルまで用意されているため、DSPのプログラマはパーツライブラリから素材をチョイスし、必要なGUIのチュートリアルをコピペするだけで、(見た目が)かなり立派なRack Extensionをビルドでき、DSPプログラミングに労力の比重を配分できる。GUIシステムがどのようにDSPと連携しているかのルールを詳細に把握する必要があるとはいえ、サンプルプロジェクト、GUIチュートリアル、パーツライブラリと至れり尽せりの開発ツール群を活用することで、当面はGUIに関しては心配無用といえる。
各種言語のコメントアウト
// C++のコメントアウト
/*
C++のコメントアウト
*/
"""
Pythonのコメントアウト
"""
'''
Pythonのコメントアウト
'''
--[[
Luaのコメントアウト
--]]
Rack Extensionの基本設定ファイル「info.lua」
デバイスの最も基本的な情報を記述する。インストゥルメントやエフェクターなどのデバイスタイプにより厳格に設定内容が異なる。リバースドメイン形式によるプロダクトIDもここで設定する。デバイスの名前もここで設定する。詳細はドキュメントの該当項目および各サンプルプロジェクトの「info.lua」を参照。
hello,world
Rack Extension Designer Tutorialの最初の項目「Hello Scenegraph」が、いわゆる「hello,world」ともいえる。多くのプログラミング言語においてそのソースコードはほんの数行で済むが、このフォルダのプロパティを見る限り、Rack Extensionの開発における「hello,world」には49のファイルと6のフォルダにおよそ200MBのデータが詰め込まれている。200MBの大半はtexturesフォルダによるもので、COLLADAのXMLなどは概ね10KB未満、大きくても100KB未満である。とはいえ「hello,world」だけで1000行以上ものXMLが必要となるのは負担が大きいと感じるかもしれないが、これらCOLLADAの3Dジオメトリは前述のパーツライブラリから供給されており、負担が大きくなるのは自らモデリングする場合に限られる。
Rack Extension Designer
JukeboxSDK(Rack Extension SDK)の中でReason Recon(開発版Reason)と並び大きな存在であるRack Extension DesignerはGUIの開発を支援してくれる。Reloadボタンがあることからも推測できるように、これはGUIエディタという位置付けとは異なり、使い慣れたテキストエディタやIDEなどでEdit→SaveそしてReloadしまたEdit→Save→Reload→Edit...といったワークフローとなる。また、Propellerheadはドキュメントの中で、本格的な3Dジオメトリに着手する前に、2Dモックアップあるいは3Dライブラリの既存のアセットを使ったGUIのクイックモックアップをPropellerheadでクリアしておくことを強く推奨している。
COLLADAとRack Extension Designer format
Parts Libraryの3Dジオメトリを注意深く読み進めると、いくつかのアートワークへの失われたリンクにたびたび遭遇するが、Reason ReconやRack Extension Designerでは正しく動作する。これはこの3Dジオメトリが制作された過程における履歴が残っているにすぎず、実際には削除されたか、あるいはRack Extension Designer formatにコンバートされてtexturesフォルダなどに移動済みか、いずれにせよ「開発ツール上で正しく動作しているならそれでよし」だと割り切り見て見ぬふりし、前に進むのが良い選択といえる。このCOLLADAのXMLについてはオフィシャルで日本語ドキュメントがある。Rack Extension Designer formatではCOLLADA 1.4を採用している。
まとめ
PropellerheadのSDK開発陣はデベロッパをよくわかっている。デベロッパはシンセやエフェクターなどを作りたいのであり、ボタンやノブを作るためにデベロッパになったわけではない。当然ながら最低限のプログラミング言語とDSPの知識は必要となるが、GUIのモデリングだのテクスチャだのは出来ることなら外注したい。ところがそれは外注せずとも最初から数百ものモデルデータやマッピング済のテクスチャなどがデベロッパには無償で提供されている。お陰様でデベロッパはDSPのプログラミングに全神経を向けることができる。もちろん器用な人はGUIのモデリングまで自らやりたいかもしれない。かなり厳格なルールがあるが、逆に言えばGUIもプリセットを使わずにカスタマイズ可能という自由さがあるともいえる。
VSTデバイスを作られた経験のある方でしたらREデバイスもおそらく難なく作れることでしょう。VSTを作った経験が無くてもReasonユーザーであればこのSDKとツール群には魅力を感じることでしょう。このページがそういった方々への入口となれば幸いです。
あとがき
情報を発信するにあたり、商用目的ではないなどの条件を満たすことで、正式な手続き「Propellerhead社への申請依頼 ⇒ 許諾」というステップをスキップし「特に許諾を得なくても公開できる」なのですが、開発ツール「JukeboxSDK」に同梱のドキュメントには「ここに記載された情報を配布しないように」との文言があります。
このページは、基本的には個人による備忘録であり「プラスαとして情報シェアの可能性も模索する」というスタンスですから、場合によってはソースの一部あるいは全部を公開する可能性も検討していますが、ソースの公開が「JukeboxSDK」に同梱のドキュメントに記載された情報を間接的に配布してしまうことにならないかについては、常に慎重に検討します。
膨大な量の素材集「3D GUI Part Library」のアーカイブには純粋に素材だけが詰まっており、いまのところドキュメントは同梱されていないようです。また、ダウンロードページにも利用規約的な文言は見当たりません。この状況を都合良くゆる～く解釈するならば「常識の範囲内でなら再配布は黙認」ともなりますし、厳格に解釈するなら「明文化するまでもなく再配布禁止」と両極端に解釈可能です(※ここで指す再配布とは「ソースプロジェクトの公開にあたり、そのプロジェクトで使用した3Dジオメトリも同梱する」という意味であり、素材を単体で再配布するといった意図ではありません)。
補足 - Propellerheads Reasonの歴史
2000年11月22日 Reason 1.0
2001年05月18日 Reason 1.0.1
2002年06月04日 Reason 2.0
2002年11月20日 Reason 2.0.1
2003年05月02日 Reason 2.5
2005年08月26日 Reason 3.0
2007年08月10日 Reason 4.0
2008年01月07日 Reason 4.0.1
2010年07月05日 Reason 5.0
2010年07月05日 Record 1.5
2010年11月19日 Reason 5.0.1
2011年12月17日 Reason 6.0
2011年12月19日 Reason 6.0.2
2012年11月08日 Reason 6.5.2
2012年12月19日 Reason 6.5.3
2013年04月26日 Reason 7.0
2013年05月15日 Reason 7.0.1
2014年04月08日 Reason 7.1.0
2014年12月16日 Reason 8.1
2015年10月30日 Reason 8.3.2
2017年08月17日 Reason 9.5.1
2017年09月20日 Reason 9.5.4
2017年10月24日 Reason 10
2018年05月07日 Reason 10.1.0
2018年09月24日 Reason 10.2.0
2018年11月28日 Reason 10.2.2
手元のReason.exeまたはFactory Sound Bank.rflのタイムスタンプなどを参照した。必ずしもリリース日と合致しているとは言いかねるが、概ねこのような歴史を辿っている。シーケンサを強化した4.0、Recordを吸収した6.0、Rack Extensionを導入した6.5とVSTに対応した9.5が大きなターニングポイントであったという見方もできるが、やはり1.0のリリースがReason史上最大のイノベーションだろう。
[連絡先]
まずはPropellerheadsアカウント
reasontrax
までPrivate Messagesをください。その後ほかの手段でコンタクトし合うか相談しましょう。
JunktraX /
+81 REASON TRAX
1995 - 2019 copyright (C) masaAki yamaguchi
|