scratch-machia

[scratch-machia]

Reasonをメイン環境に戻せそう。

概要

Propellerhead ReasonというDAWソフトでステップシーケンサが使えるようになってReasonをメイン環境に戻せそうなのでメモった。

利用する楽器

Reasonの楽器（組みこみ）

RackExtension（Reasonの拡張楽器・エフェクタ）

VSTi/VST（ソフトウェア拡張） これはViennaEnsembleProを起動して鳴らす

ステップシーケンサ

Reason上でステップシーケンサが使えるようになった。 これによってキーボードからの打ち込み情報入力が可能になった。 ただマウスは必要になるので、PCに関する全デバイス使う感じではある。

利点

Reason自体が強制終了しづらい

VSTホストとしての機能は殆ど使わないので、強制終了��る要因が少ない

制約

VSTについてはプリセットを使うとトラック追加しないと打ち込みはできない（デバイス更に追加すればステップシーケンサを動かせるのでそれほど気にしなくてもいいけど、もしくは1個ずつデバイス追加で対応可能）

Live組み込みとかの楽器が使えない→RewireでLiveをホストにすれば問題ない

VSTについては1trあたり1アウトプットの制約がある（マルチアウトできない）→録音するか複数IPでVSTを起動することで対応可能

以上、ちょっとメモってみました。 今回Markdown記法使ってみたけど、エディタ上での記述はバグりすぎてやってらんねえ。

[scratch-machia]

現状のDAWとのつきあい方

AbletonLive VST・Max for Live・Rewire・DAW組み込みの楽器を使ったメインの作曲環境。 比較的大規模の曲を書くときはよく使うし、メモ程度の曲にするときも使う。 アプリが落ちることがたまにあるのでバックアップは欠かせない。（Live側でもバックアップとってる）

Propellerhead Reason クローズドな環境で曲を書くときに使う。 あまり強制終了しないので、信頼に足る楽器としてスケッチを書くことも多い。

PreSonus StudioOne マスタリングで利用する。 あと波形を調整するときも使う。 （本来なら波形補正は別のソフト使うほうが早い気がするけど）

[scratch-machia]

■タチやんさんの「音楽というものとDTMの関係について」の私の回答

なんかあどにゃんこと宮崎さんが面白そうなのに回答してるので、自分も回答してみた。

ちなみにあたしはこれらの楽曲の主にピアノを担当しとります。打ち込み フル打ち込みで作ってます。

・楽譜の読み書きができない作曲家（自分も該当する）を生み出したDTMの功罪について

　特段なし。 　 　単に楽譜読み書きができる人がお金もらって曲書くケースが多いかと思うし、 　 　その中で音鳴らすカテゴリとしてDTMが存在するという認識。

・同じく、楽器の演奏ができない作曲家もDTMは生み出している

　そうだね、自分だね。 　 　単にアウトプットの選択肢と媒体が増えた、という程度。

・DTMは音楽制作の敷居を圧倒的に低くしたとは思う。 　では、学術・アカデミックな分野においてDTMはどう扱われているか？ 　そこまでの参入への敷居を低くはできたか？（できてないと個人的には思う）

楽器の延長上としての参入の敷居を下げるのは出来てると思う。 バークリー大学だったかでReasonを導入したとかあったけど、 アレ1本だけで色んな音出せるかんね。そりゃ楽器を用意しなくて良いわけだよ。

あとクセナキスの曲とかさ。確かなんかごついタッチペンで演奏してた 楽曲があったようななかったような。

そこまでになってくると演奏＋コンピュータを利用した楽曲だから 敷居の高い低いというより、単にやれることが増えてきてると思う。 そういう意味では「選択肢が増えた」とするのが適切かと。

・DTMは楽譜化ができない、もしくは著しく困難な楽曲を作ることも可能としたと思われる。 これは本当にそうなのか、楽譜のフォーマットに限界がないか、 拡張はできないか？など考えられる。

　定量的なピッチベンドを書き記せない時点でそれが楽譜の限界と思う。 MIDI→楽譜に落とせるか、という話で、あとは粒度の問題。

楽譜がその粒度で問題ない状態になってるのは、 単に奏者の解���を許しているかと思う。

よって、奏者を誰にするかで必要な粒度はいくらでも変わる。

じゃあ奏者に合わせた楽譜をどうやって作るか、って問題になるけど、カスタマイズできる項目を揃えたりしない限り工業化は難しいよ。

MIDIでええやん、ってなる。

・演奏家から見たDTM・打ち込み音楽の音についてはどうか？

最近はあまり気にならない。 楽器がデジタル化しているというのもあるけど、 そもそもMIDI対応楽器による人間の演奏をクォンタイズすれば 打ち込みの演奏っぽくなるんだから、強弱・デュレーション・タイミングを 全部データ化できれば再現できちまうじゃねえか、と。 じゃあそうなった場合って打ち込みと演奏の違いってどんなのだろうね、と 考えてしまうのよ。

　だから自分は単純に「曲をデータ化するまでの速度・プロセスが違う」と捉えてる。 演奏家からすると演奏をデータとして打ち込むのめんどくさく見えるかもしれんけど 自分にとっては打ち込みよりも演奏のほうがムズいわい、と。 打ち込みで演奏っぽいアプローチで打ち込んでいくほうがマシ。

MIDI対応楽器を演奏しない場合は別カテゴリ。 これは独自の楽器を演奏しているって位置づけになるので共存は できると思う。

・DTMでは可能だが、人間では到底演奏不可能な音・作曲についてはどうだろう？

テクノ全般。 狂いなくリズムをずっと叩き続けてられるか、という話。 あとサンプリング音楽全般。

あとサーカスギャロップとかはまさに人間が演奏するというより 自動ピアノのための楽曲。

■自分のスタンスと結論

　打ち込みメイン。 　ただ演奏は「打ち込みでやらなきゃいけない作業をだいぶ簡略化できる」ので、 　その入力手段として使うのはアリかと。 　どっちが早いかで決めりゃ良い。 　 　生演奏は強弱・デュレーション・タイミング等を弄るもの、 　それ以外はタイミングをカッチリにして入力するもの、として楽曲を作る。

[scratch-machia]

アリス・ギア・アイギスDMM GAMES版をプレイするときの設定メモ。

概要

アリス・ギア・アイギスは元々iOS/Androidでサービス開始、最近DMM GAMESでプレイできるようになりました。 https://colopl.co.jp/alicegearaegis/lp/dmg/ ただ、使用しているシステムの関係でうまく動作しないことがあるみたいなので、メモ程度に必要そうな設定を残しときます。

仕組み

どうも、AndroidアプリケーションをBlueStacksという仮想基盤上で動かしているらしい。 参考資料 https://www.4gamer.net/games/999/G999905/20180419054/

サポート

で、何が問題なのかと言うと、 「準備なしで動かす場合、動作がものすごく遅いことがある」ということ。 どうも仮想システムで動かす関係上各種機器が対応していない場合設定が必要みたい。 https://support.bluestacks.com/hc/ja/articles/115003193326--BlueStacks%E3%81%AE%E5%8B%95%E4%BD%9C%E3%81%8C%E9%81%85%E3%81%84-%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E8%A7%A3%E6%B1%BA%E7%AD%96 （最新のバージョンだと変わるかもしれないけど） 特に一番影響ありそうなのはここかなあ、と。 https://support.bluestacks.com/hc/en-us/articles/115003174386-How-can-I-enable-virtualization-VT-on-my-PC-

vt-xとは

https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%86%E3%83%AB_%E3%83%90%E3%83%BC%E3%83%81%E3%83%A3%E3%83%A9%E3%82%A4%E3%82%BC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%BB%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC 簡単に言うと、仮想化に対しハードウェア側で対応するということ。 これによって、BlusStacksアプリの性能向上が見込めます。

クライアント側だと何が必要か

vt-xとvt-dが最低限必要と思われます。 （設定しないで早く動けば問題はないので設定変更必要ないです）

設定方法

BIOS/UEFIからVirtualizationとかvt-dと記載されている項目があるので、これをEnableとかにしちゃってください（機種やBIOS/UEFIによって違う）

※ BIOS/UEFI・・・簡単に言うとOS起動前にいじれる、ハードウェアを管理するためのメニューみたいなの。

[scratch-machia]

クリエイティブ・コーディング環境・ORCΛ導入。

■概要

ORCΛは、コーディングによって一定時間で特定メッセージを出力する等のシーケンスを作成することが可能。 作ったシーケンスはMIDIメッセージやOSCのメッセージとして出力が可能。 これらをリアルタイムでコーディングしていくことで楽曲を作成していくクリエイティブコーディング用のツールっぽい。 ただ、受け皿となるMIDI IN/OUTがないと対応できないので別途入出力先の設定が必要になる。

[scratch-machia]

Epic Orchestra 2.0を使用した。

■概要

前��の記事でVienna Ensemble Pro6を導入した内容を記載したが、これには付属でオーケストラライブラリがついている。Epic Orchestra 2.0はそのライブラリの名前。

■こんな音

https://twitter.com/__machia__/status/1109402670521958401

■感想

細かいアーティキュレーションは入ってないけど、よく使いそうなものが入ってる。（レガートとかショートとか。あと大編成とChamberとか）

■その他

SynchronPlayerは、どうもリアルタイムでメモリ搭載内容を変更するらしいので、生演奏を反映させるのだと使いづらい。編曲用途で使うのがよさそう。

[scratch-machia]

Vienna Ensemble Pro導入。

概要、メリデメ、使用用途について走り書きしときます。

■概要

VEPとは、DAWとは別プロセスで起動するアプリケーションである。 アプリ内にVST/AUを読み込めて、これをDAWと連携して使う。 スーパー乱暴な言い方だとRewireに近い使い方ができる。

■詳細

VEPはサーバプログラムとしてPC内に起動して使う。 この中にVST/AU等プラグインを読み込むことができる。 使用するときはサーバクライアント型のアプリケーションとして使う。

具体的には、以下の流れ。

DAW上でVEPサーバ接続アプリ（VST）インスタンス作成

VEPアプリから特定サーバへ接続する

VEPが外部プロセスで起動する音源として動く

以下、特徴を記載。

他のPCで起動および連携が可能。すなわち複数台PCを用意して、 DAW用PCとVST再生用PC、という形での分割が可能。

DAWのエクスポートにも対応。オフラインレンダリングが可能

複数のプラグイン規格を混ぜて利用可能。 DAWからは読み込んだ先はMIDIトラックでやりとりを行うため、 VEPで32/64bitVST両方を読み込んだり、AUを読み込んだりできるみたい（Mac限定）

CPU効率に優れてる・・・みたいだけどいまいちその恩恵にあずかれねえ

VEP上でInstへのエフェクトは利用可能。（VST読込可能） ただ、オーディオのルーティング可否は未確認。 （例：DAW→VEP→DAW）

■メリット

DAWと別プロセスで動くので、VST読み込んだおかげでDAWを巻き込んで強制終了することが少なくなる。

VSTを他のPCで起動することで、負荷分散が可能になる

DAWを使い分ける際、VEPを1インスタンス起動しておけばVSTを共有できるので、DAWを開いて毎回VSTを読み込む手間が省ける （例：ギターやオーケストラの大容量サンプル）

■デメリット

DAWとVEP、2個のソフトウェアを使っていくため、操作が煩雑になる

DAW側でVEPが正常に読み込めない場合どうしようもない

VEPを起動した分、DAW単体を起動するよりも負荷は増大するため、それを許容する分のPCの性能は必要

複数台を使う場合、DAW操作の知識以外にネットワーク関連の知識が必要

■こういう人は使ったほうが良いかも

大規模なオケとか作る人、ごりごり大容量ギターやベース音源を使う人（俺 あらかじめオケや音源のテンプレートを読込できる 16パート以上使う場合もインスタンス分けて読み込めば対応可能

複数のDAWを使い分ける人（俺 一度インスタンスを起動すれば、あとはDAWで読み込むデータは 少なく抑えられるため、リトライや強制終了時の手戻り時間は最小限になる

DAWと相性の悪いVSTを使ってる人（俺 少なくともVEPのインスタンスが作成できればなんとかなる

DAWとRewire使うようなひと 操作が煩雑になるけど、使い方はRewireと似たような感じになる

■その他

VEP上で設定するレイテンシーは演奏に関するレイテンシー。この値が大きいほど反応がよくなるみたい。ただDAWのオーディオエンジンにもアクセスしているらしく、一部のDAW（FLStudio、Reasonで確認）だと音切れが発生する。このケースではレイテンシーを「none」にすることで回避可能 参考資料： https://www.vsl.co.at/community/posts/t48271-Is-VEP-compatible-with-FL-Studio#post269154

16トラック以上使う場合は、インスタンスを複数起動すること。（あくまでインスタンス1個で16trまで、という形らしい）

マルチティンバー音源と同じような扱いと考えたほうが良いため、マルチティンバーに対応してないDAW（例：Reason）では実質1trしか使えないことに注意

[scratch-machia]

Rewireの組み合わせ。

前の記事でAbletonLiveに移行したと書きながらまだFLStudio使ってます。 とは言うものの、選択肢は結構限られてくる感じですね。

今回はRewireのメモ残しておきます。 FLStudio・Reason・AbletonLiveの組み合わせを調べました。

20190630現在の結論： AbletonLive+Reasonで使う一択。

FLStudio（ホスト）→Reason（スレーブ） かなり運用が辛い組み合わせ。 現状のReasonの仕様として「ミキサー・Inst・エフェクタをすべて同じ種類のトラックとして登録する」状態、かつFLStudio側でそれらのトラックをすべて読み込むおかげで、エフェクタやミキサーにもトラックが割り当てられて、MIDIトラックが歯抜け状態になってしまう。 Reasonの1バスが埋まったら2バス以降を指定するけど、各種デバイス載せてるうちにバスは消費されてしまうため、そのたび設定し直すのも辛い。 今の所1トラックのシンセを構築するのにReason使う、という選択肢くらいしかない。

FLStudio（ホスト）→AbletonLive（スレーブ） 意外と動作が安定している組み合わせ。 VSTに加えてAbletonLive内蔵のシンセ・エフェクタ・MaxForLiveのデバイス等使えるものがかなり多くなる上、FL→Reasonのような仕様も存在せず、トラックとコントロールを簡単に対応できる。（そもそもRewireの仕様自体ミキサーを模してるんだろうなあ） ということで安定度が高い組み合わせとなる。 下に追記したけど、MaxForLiveは使えない。ということでFLStudioのシーケンサ使う用がない限り選ぶものではなくなってる。今だとVEP使うだけでいい。

AbletonLive（ホスト）→Reason（スレーブ） これも安定度が高い組み合わせ。 MaxForLive・RackExtensionという公式のデバイスを2種類使えるほか、Liveのミキサーからコントロール可能なデバイスを直に指定できるため、視認性が高い。

（20190120追記）AbletonLive（ホスト）→FLStudio（スレーブ） AbletonLiveがホストじゃないとMaxForLiveが使えないという仕様が判明。 あとFLStudioのシーケンスを一部使いたいならこの組み合わせだけど、正直それだったらFLStudio+VEPの組み合わせでOKになる。 更に言うと最近の環境整備によって、AbletonLive単体での入力効率化が進んだため、RewireのスレーブにFLを採用する理由がなくなった。

とこんな感じ。 Cubase/SONARとかは使ってないので調べてません。 あとStudioOneは持ってるけどアレで打ち込みする気は起きないのでもっぱらマスタリング専用DAWになってます。

ひとつずつ譜面打ち込むより、フレーズの塊で曲を作る考えなので、それに準ずるDAWを選んでしまう感じですね・・・

[scratch-machia]

AbletonLive使い始めた。

去年からなんですけど、長年使っていた（多分10年くらい使ってたんじゃないかな）FLStudioからAbletonLiveにメインシーケンサを乗り換えました。

Reasonとかも使ってたけど、まぁメインをどうするかで悩んでたんですね。

■移行理由

気分転換ですｗ あと、やはりVSTの規格そのものがかなりカオスで使ってられなくなった状態です。 KONTAKTはサンプル多すぎるし重いし落ちるしorz あと各DAWで読込の状態が違いすぎて使えないケースがあったりして、 VST依存でDAWを選択するのが嫌になったんですね。

となると、それ以外の専用の規格をもったDAWを選んだほうが閉じた環境での拡張があると考えて選びました。（とは言うもののVSTも一部必要ではあるので、サブ的に使用できるDAW、という条件もプラス） ちなみに、FLも独自プラグイン持ってるけど、拡張はできないので対象から外しました。あとProtoolsもどちらかというと特殊な環境扱いで対象からは除外してます。

まず第一優先は自分が持ってたReason。 Reason単体で作曲しても問題ないかな、と思いましたが、他DAWとの連携を考えると少し物足りなさを感じました。 とは言うものの単体でRackExtensionを使って作曲するのは魅力です。

次の選択肢としてAbletonLiveを選びました。 Maxとの連携によるMaxForLiveが一番興味ありました。 あと内部のエフェクターやシンセを見てもかなり使いやすかったんですね。

とどっちも使い込んでいく中で、AbletonLiveが結構よさそうな点がいくつか見つかってきました。

ほぼPCキーボードだけで作曲できる ショートカットに加えて、ステップ入力ができるということに気づいたためです。（Ver.9から導入されたそうで） また、PCキーボードを鍵盤のように使うことが可能になってます。 これによって、鍵盤を殆どいじらずに作曲や音の確認が可能になりました。（ReasonはPCキーボードを鍵盤にする機能だけあったんですよね） パラメータの一部・ボタン等でショートカットがきかない（キー割当もない）ものは存在しますが、それを差し引いてもPCキーボードだけで作曲できるのはありがたいです。 自分が鍵盤使うの苦手なのでｗ

オーディオの取扱が楽 録音してからそれをループさせるのに、ループの取扱が簡単に行えるのは嬉しいです。（再生-終了位置を決めるだけ） あと、オーディオも補間してるっぽくてWAVを切ったときのプチノイズ等が目立たなくなってるので、神経質にならずにフレーズ等を作り込めます。

MIDI周りの連携が楽 コントローラを登録して使うのがすごい楽ですし、パラメータとツマミの関連づけもLiveから触れるところにスイッチがあるのが便利です。 あとコントロールサーフェスを使っていくと更に便利になってくところも嬉しいです。

ルーティングが自由 最近ハードシンセを使ってるんですが、「ハードシンセの入力とソフトシンセの出力を混ぜて出力してそれを録音する」みたいなのが簡単に行えるんですね。他DAWでも同じようなことはできるとおもうんですが、クリップビューで譜面書きつつハードシンセをいじって録音するとかできて、作曲と録音が簡単に行えました。

ということで今のところAbletonLiveをどんどん使ってます。 ReasonもRewireで呼び出して使えるので、RackExtensionも使えます。 今まであったVSTに関するストレスについては、Live組み込みの楽器で代替���きるようになったため、頻繁に使用するもの以外はほぼなくなってスッキリしました。

[scratch-machia]

Pianoの入力方法まとめ

自分のピアノ演奏情報入力方法をまとめとく。 M3新譜作成後、情報を整理・更新して結構様変わりしてるのもあって、書かないと忘れると思いまして。

もってる道具

鍵盤（OP-1、A-01、SE-02、CP4Stage。譜面のリアルタイム演奏等）

打ち込み（マウス。譜面の入力と各種パラメータの調整）

LightPadBlockM（Sustain等パラメータ入力用）

ペダル（CP4Stageに接続して使う、サステインペダルじゃないと関節痛める）

方法（2018/10/9現在）

鍵盤かマウスで譜面を打ち込む バッキングは演奏の方がいいけどクォンタイズかけるのでどっちでもいいと思う

LightpadBlockMでSustain情報を入力しつつリアルタイムで演奏

マウスでVelocity・Sustain微調整

[scratch-machia]

VisualStudioの設定絡みのメモ

今TokyoDemoFest向けの実行ファイル作ってんだけど、ハマったマジで。 2018/9/24 VisualStudio2017Communityで設定を構築したので情報追記。 2018/11/2 64bit環境でコンパイルが失敗する挙動について追記。

VisualStudio上の設定は自動セーブされる。 具体的には、自分の場合以下の項目でちょっと気をつけなきゃいけないぽい。 オプションの設定でオブジェクトファイル作成後、リンク時に落っこちる 調べてみたら、オプションでオブジェクトファイルに余計な記述加えることがあるらしく、それで落っこちる可能性がある、ということ。 わけわからないエラーでビルドが失敗し続けてるなら一度プロジェクト作り直すのも手

ベース資料（これベースに作ってます。のたぐすさんとこ） http://wordpress.notargs.com/blog/blog/2015/02/28/%E3%83%A1%E3%82%AC%E3%83%87%E3%83%A2visualstudio2013%E3%81%A74kb%E3%81%AEexe%E3%82%92%E4%BD%9C%E3%82%8B/ ちなみに追記で、$(SolutionDir)を指定する時に、「パスの一番先頭に持ってこないと最初にCrinkler��処理されない」らしいので注意。 参考資料： http://nanka.hateblo.jp/entry/2018/07/01/034341

バッファセキュリティチェックについて 「@__security_check_cookie@xが関数～で参照されました」というエラーが出ることがある。 どうやらバッファオーバーランを検知するためのコードを埋め込むみたいで、不要なので削除する。 普通のプログラムだったらあっても問題ないけど、サイズに著しく制限がかかる場合、入念なテストの上コードを抜くという選択肢を採用 今回は、 C/C++→コード生成→セキュリティチェック→セキュリティチェックを無効にします を選択して対応（これ設定するとSDLより優先されるので、他でSDLチェックしていても大丈夫になる） 参考資料： http://d.hatena.ne.jp/yellow_73/20070905

エラーの内容

アセンブラコードでFloat取り扱うときの注意点 なんか一部命令がうまく認識しないみたい。 よって、最初から最適化させて対応するのが早い。 構成プロパティ→C/C++→最適化→最適化 項目「無効」以外を選択する。 これで認識するようになる。 もしくは自分でfloat取扱用のアセンブラコード書くか。

パスに日本語を使わない方がいい 海外ソフトにありがちなんだけど、 Crinklerでリンク処理行うとき、ファイルの置き場所に日本語パスを指定してると文字が化けるので、正確なパスを参照できなくてエラーコード吐くという。 日本語を含まないパスにファイルを置く ことで解決するケースあり。 どちらかというとアプリケーション側でマルチバイト対応していないがゆえに起こる問題。 （ただ英語圏のソフトに対応を求めるのもおかしな話なので、個人で対応できたほうが早い）

サブシステムがクリアされてるケース 新規にプロジェクト作成した場合、サブシステムが設定されてないのでエラー吐くことがある。 リンカ→システム→サブシステム→SUBSYSTEM:Windows を定義して対応。

Crinklerは最新のものを使おう 何でかというと、元々結構過去のシステムへの対応してたみたいだけど、見たところWindowsSDKへの対応がかなり時間かかってたっぽい気が。具体的には、古いCrinklerを使うと謎のエラーでCrinklerが異常終了するので、それを回避する形になると時間がかかる。 2018/9/24現在、同年更新されたファイルがあるので、それ使うとエラーが発生しなくなる。

glext.hからの呼び出しファイルが不足する 自分の環境では、 #include <KHR/khrplatform.h> って記述が正常に読み込まれなかったので改造して対応した。 （ヘッダファイルとして読み込めればとりあえず問題はないので、VCのヘッダファイル集めてるフォルダに投げ込めば認識はしてくれる様子） ちなみに上記ソースは、各プラットフォーム特有の定義らしく、更新頻度は高いんじゃないかと思ってる。

64bit環境でアセンブラは使いづらい https://www.officedaytime.com/tips/asm64/ https://kagasu.hatenablog.com/entry/2018/01/03/200337 64bit環境でインラインアセンブラの記述が使えないため、 別途アセンブラ言語ファイルを記述、masmでアセンブルする必要あり。 もしくはCompiler Intrinsicsの導入を検討。

[scratch-machia]

ピアノを入れる時に必要そうな要素。

メモ書きだよ。 もちろん全部ではないけど、情報まとめといたほうが自分も参考になる。

タイミングの前後をバラけさせる

強弱をつける

サステインペダルを使う ただペダリングは小節の最後にオフにする また、ペダリングオンのときは前の小節から入れておくのが効果的

バッキングにサステインを使ってコードを埋める 音源による部分があるので、音源の挙動を確認しておく どうもペダルによって減衰するスピードが変わるみたいなので、少し柔らかめにコード使うときはペダルつかってもいいかもしれない

ハキハキしたフレーズにはペダルを入れるのは逆に聞きづらくなるのでペダルを入れないで対応

バッキングのときも左右の腕で少し違うフレーズを演奏

[scratch-machia]

UVI Falconのコントロール方法

・Program作成→Layer作成→KeyGroup作成の順番で階層が下がっていく ・KeyGroupの階層下にOscilatorを作成する ・KeyGroup階層下・Layer階層下・Program階層下にModulation作成可能。 ・パラメータにドラッグ＆ドロップすることでModulate対象を決定 この時、Program→Layer・KeyGroupのモジュールに反映可能 Layer→KeyGroupに反映可能 KeyGroup→Layerに反映可能（ここらへんよーわからん） ・ModulationSourceの振動タイミングはモジュールによって違う（設定可能？） ・エフェクトはラッキング形式 ・Program階層・Layer階層内にアルペジエータを設置可能 これで複雑なパターンを構築可能。

とりあえずこれで音源が作成できそう。

[scratch-machia]

Propellerhead Reasonでエフェクトを鍵盤で操作する方法。

整理がてらメモ。 元々Reason上でStutterEditを使いたかったので。

方法

エフェクト追加する

エフェクトのトラックを作成する

エフェクトのノートレーン作成する

これで鍵盤シーケンスを記録できる。

[scratch-machia]

ScriptableObject使って爆発エフェクト作成なう

画像みたいなエフェクト作りたかったもので。

簡単に実装方法を記入しときます。

ScriptableObjectで頂点座標や消滅フレーム数等を入れられるようにする

簡単なマネージャクラスを作ってその中でScriptableObjectからデータ生成できるようにする

上のスクショでは、遅延時間を設定して、生成タイミングをズラした爆発エフェクトを表示させたりしてます。

結構爆発は豪快に使うかと思うので、こういう小回りのきくクラスが一個くらいあると役に立つかな、と。

[scratch-machia]

ついったに映像あっぷする場合の注意点

https://mntone.hateblo.jp/entry/2015/08/08/111228

結構劣化するので。

[scratch-machia]

爆発エフェクト書く資料

http://seesaawiki.jp/game-sozai/d/%C7%FA%C8%AF%A5%A8%A5%D5%A5%A7%A5%AF%A5%C8%A5%A2%A5%CB%A5%E1%40EDGE%A1%CA2%A1%CB

完全になにも書いたことがないレベルでもどうにかなった