不調なPacaranaの代わりにCapyを復活させた

11月16日は久々のギグに参加する予定があり、これに合わせてPacranaを起動してライヴシステムを組み直そうとしたところ、アプリを立ち上げた途端に温度超過のアラートが出て電源が落とされる現象に悩まされた。



原因は温度管理を兼ねたファンコントローラにありそうだということで、ハンダのクラックを想定してリフローを行ったが、問題は解決せず。



仕方がないので、該当する部品の発注を行いつつ、手持ちの機材でなんとか出来ないかと、死蔵していたCapybaraを復活させることになった。



CapybaraにはアナログI/Oが装備されているがレベルの管理は行えず、外部に卓が必須となるのだが、今回はRMEと組み合わせることになった。



問題は、手持ちのmidi系デバイスの殆どがWireles化されていたことで、デバイスからの信号をCapyは直接受けることが出来ない。



rtp-midiに関しては信号をmidiインターフェイスにアサインし、そこから有線でCapyに繋げることが出来たが、この回線にMotorMixを絡ませようとしても、MidiThruが行えないmidiインターフェイスがMotorMixからの出力を堰き止めてしまう。



この問題を解決するには、midi信号をミックスするMidiMergerが必要となるが、5VトレラントなMCUとして手持ちのTeensy3.5が使えそうだ。　midi受けには在庫していた6N137を、出力のレベルシフトには74LVC1G34を使用することにした。



当初はMergeが上手くいかなかったが、単純にポートの接続を間違えていたことが原因で、配線を修正してからは呆気なくMergeを行うことが出来た。



ArduinoのMidiライブラリはデフォルトでThruがオンな仕様で、受けた信号をPortAに集約することで自動的にMergeが行われる。　完成したMergerはCapyに組み込みたいところだったが、ここは時間切れでバラック構造で折衷することになった。



会場では、このような形でシステムを展開していた。





ギグを行った過程で感じた設置の手間とインターフェイスのハンドリングの困難さから、やはりWifi化は必須と判断し、在庫していたXBeeを投入することにしたのだが、、、最新の設定アプリはmidi信号のBaudRateに対応しておらず、、、



結局は旧いWindows対応のアプリを使うことになった。



アドレス3927は、受け側なので、これをMidiMergerの入力のうち1chに接続する。通信帯は”C"に設定している。　対するアドレス3721は送信側で、これをCapyの出力にバッファを介して接続する。

注意すべき点は近接するXBeeとの混信を避けるために通信帯をDchに設定していることで、この変更を失念してしまうと通信が行えなくなってしまう。



パーツの実装密度を上げるために、個別に展開していたフォトカプラをDualTypeのものに変更した。



ブレッドボード上にXBeeを含めた入力系を集約しているが、ここにLEDで入力信号の確認を行う仕掛けを追加する予定。

プレイバックサンプラーにタブラのベンド奏法っぽい効果を追加する

バスドラム担当のプレイバックサンプラーにベンド機能を実装した。



速いパッセージに対応しきれていないが、それっぽい雰囲気は出せている。

再生できない場合、ダウンロードは🎥こちら

ADSRの調整箇所はAttackのみ。　印加するベンド情報はスイッチ系オブジェクトのオン・オフでは切替えず、フェーダーによって掛かりの調整を行う。　

フェーダーの選択は正解で、ベンドカーヴを微妙にコントロールすることができた。

今回の改装ではフィルターバンクのBandWidthを閉じて発振を発生させるエフェクトを強化するために、コントローラーに設定していた時定数を1sから0.3sに変更して追従性を上げつつ、BWの開度によってレベルを調整する（開度が0に近づくにつれて出力レベルが上昇する）機構を追加している。

BPMの変更に伴って破綻が発生する現象をフィックスした

BPMを遅い方向にセッティングした瞬間に処理が破綻してオーディオインターフェイスを見失う案件が発生、対処に苦慮させられる。

オブジェクトの負荷を⌘＆Iで調べると、Compressorの消費量が予想以上に大きいことが発覚したので、



可能な限り無駄な配置をしているものを省いた。



恐ろしいのはRevPianoで、



なんとリザルトが1000％を超えていた。　



最終的には6割ほどまで処理を圧縮できたが、それでも100％を超えてしまう。　ちなみにPakaranaにコンパイルした後の実測値は33％程なので、



何故そこまで異常な消費判定になるのか原因が判らないが、このパートの構成そのもの非常に怪しくなってくる。



ひとまず、過大な処理の元凶と発覚したRevPianoを放置して、コンパイルのプライオリティーを変更するためにFilterBankの開始時間を0secに移動したところ、98％前後をうろついていた処理量を最大で95％まで圧縮することができた。　他のDSPの消費量も90％未満に抑えたので、変動に対するマージンはより大きくなっている。　



更にダイエットを行った結果。



以上の変更で、BPMの変更やTapによる短いループをマスターにする機能を選択した場合でも破綻は起こらなくなった。

BassSyntheのMuteSwitch周りを改良する

無駄に複雑化させていたBassSyntheのVolume制御系をシンプルな構成に改良した。

まずは出口側のオブジェクトから、ADSRのゲート入力に該当するスイッチをアサインしつつ、上流に接続したオブジェクトのOutputLevelからスイッチを排除して固定出力とする。レベル設定を行うVCSはScaleに配置する。



OutputLevelを動的制御した場合、データを更新するスピードの限界によってどうしても精度が荒くなってしまうので、ホットパラメーターの配置には注意を払わなければならない。



同様に、オシレーター直近のADSRのScaleからも動的制御を行うパラメーターを取り除いている。



今回の変更によって長音の後に配置した短いパッセージ(―・・)に取りこぼしが発生しだしたため、Gateの制御信号に行っていたSmoothingを10msから8msに変更している。

今日のダイエット

PulseTrainのGate入力に接続されていたGraphicalEnvelopeを廃して !ABswitch でGateを直接駆動する方法でDSP消費量のダイエットを行った。

ループ同期信号ジェネレーターの改良を行う

サブ録音ユニットがマスター録音ユニットよりも長尺の録音を行った場合に、マスターループの同期を行うリセット信号にサブループが強制同期させられて、サブループに録音された音声が完全に再生されない不具合を　triggerEvery:　を使って、、、



!MagC と !StepA(B) の比率でトリガーが発生する周期の倍率を決定する手法で解消している。

FVCに大改装を行う

順調に思われていたTimelineの再構築だったが、ピッチ(周波数)ディテクタの入力を切替えた途端にDSPの処理が破綻してしまった。

以前からフォルマントシンセのFilterFrequencyを絞っただけで、タスクが微増する謎な現象が観測されていたが、この破綻は別系統の処理に由来するもので、FVC = Frequency to Value Converter周りに問題があるようだ。　当たるも八卦な黒魔術の行使がそろそろ限界な情況となりつつあるため、今回は正攻法でもって不具合に対処しなければならない。

特に怪しい箇所は録音オブジェクトAに実装しているピッチディテクタで、これの上流に接続された入力セレクタを操作して音声信号を入力した途端にシステムがフリーズを起こすのだが、録音した音源をソースに選んだ場合には何故か問題が発生しない。　何れにしても、処理自体はリアルタイムで行われている情況でフリーズが発生する・しない原因がサッパリ解らないのだが、ここはひとまず対症療法で生楽器の入力を別トラックに移すことにした。





ちなみに、現時点で稼働しているピッチディテクタは、録音トラックA/B/C*2のグループと音源RevPiano上の3基の計7基で、このうち音源をダイレクトにコントロールするFVCliveにはRevPiano上の1基を割当ている。このFVCliveを音声入力専用に作り直し、録音トラックA/B上の音声入力を廃止する。

ディテクタのオブジェクトでは入力が途切れた瞬間に出力値が自動的に固定されるが、Readoutした値そのものをデータバスを通して扱う場合は　initialSanpleAndHold:　を使って出力値をラッチする必要がある。



ただ、このディテクタはRevPianoとの共用なので、値をロックすると音源側の運用ができなくなってしまった。　結局、機能を両立させるには音声入力専用のディテクタをあと1個追加する必要があった。

リアルタイム系の楽器オブジェクトはピッチ入力をmidiと共用するための処理系統が複雑なのだが、今回改装を行った GranularSynthe では直接入力への対応を強化している。



この音源はピッチ感の無いフレーキー？な効果音発生器としての運用が可能で、その場合は入力される信号がトリガーとして扱われる。　録音トラック"C"を使用すれば長周期のタイミングコントロールが可能だ。

DSPの消費量はタスクの変動により推移する。



FormantSyntheオブジェクトやピッチディテクタを稼働させた場合に数％消費量が変動することを確認しているが、まだ他に隠れた要素が存在しているかもしれない。

生演奏で怖いのはこの手の変動が予想外の組み合わせで発生した時で、追加の処理が重タスク環境下のDSPに割り振られた瞬間にシステムが破綻してしまう。

ちなみに今回体験したのは、ピッチディテクタに入力する音声信号の周波数が、しきい値(もちろん設定した覚えはない)を超えた瞬間に処理の破綻が始まるという悪夢のような現象だった。

数年前に仕様変更が行われたAnalogSequencerオブジェクトの改修をようやく行う

数年前に仕様変更が行われてから従来の使い方が出来なくなっていたBassSyntheの本格的な改修を行った。



何時もの「用法でカヴァー」という悪癖の継続を止めて、本格的に楽器の構成自体を再検討しているのだが、完全な再現は難しいようだ。



問題はどうやってもStep毎に音が途切れてしまう現象で、これは!KeyDownのリトリガーがStep毎に掛かる仕様に原因があるようだ。　本来はDutycycle設定パラメーターを"1.0"にセットすると!KeyDownのリトリガーは排除される筈なのだが、これが理屈道理には働かず音符がレガートにならない。最小値の側も同様で、論理値の「ゼロ」にはならず、実際の出力値は0.001から0.999辺りといったところだろうか。

AnalogSequencerの内部で事が完結出来そうにないので、接続先の音源ソース側の設定を精査したところ、本来は!KeyDownがアサインされる筈のGateインプットには!KeyVelocityが記述されていた。

要はVelocityによってGateをコントロールしているのだが、この方式ではStep毎にリトリガーを掛けることが出来なくなってしまう。



そこで検討したのは、!KeyDownとスレッショルド設定した!KeyVelocityの論理和でトリガーを掛けることで、!KeyVelocityの値が規定値を超えた場合にのみ、新たな!KeyDownをマスクする仕掛けだ。



当初は、思惑通りに機能が働かず、マスクを失敗した結果発生する「信号のヒゲ=ジッター」に悩まされることになったが、



アナログ値からデジタル値に変換を行う前にスムージングを行うことで、ジッターの発生を回避することができた。

再生できない場合、ダウンロードは🎥こちら

追記：

TripletEGをアクティベートするホットパラメーター !TripletEvent のズレがそのままノイズになって仕舞う現象が発覚したため、該当する箇所にノイズサプレッサーを追加している。

今日の小改装

録音開始のマーカーとしての機能も担っているPercussionサンプルの再生機にAttackTimeが設定できるEGを追加した。



Delay3系統と、、、





NoiseVocorderの出力には、TripletEnvelopeを実装している。



その後、パーカッション再生オブジェクトのトリガー系に配置していたEGを撤廃したところ、タスクが劇的に減った。



ここではEGの出力をサンプル再生オブジェクトに分配していたのだが、コンパイラ側ではこれを「並列配置」と解釈していたフシがあって、この部分をオブジェクトのパラメーターボックスにスクリプトの形で分散表記した結果、7%以上もタスクを減らすことが出来た。

どうもEG系オブジェクトは想像していたよりも処理が重くなる傾向があるようで、この辺りの構造を合理化して処理を軽く出来るかもしれない。



パーカッション系のマルチソースを読み出すサンプラーと、



ステップ再生タイプのサンプラーからは既に該当するEGを撤去しているが、動作に支障はなかった。

DSPの処理分配について

GranularDelayの出力をTripletEnvelopeGeneratorでコントロールしている。

再生できない場合、ダウンロードは🎥こちら

DSPの分配を調整するのは至難の業だったが、今回はTimelineのRowを入れ替える方法でなんとか稼動状態に持ち込めた。



これは、試行錯誤を行う過程でDSPの処理パターンを観察した結果思いついた手法で、トラックの位置を変えることでコンパイルのプライオリティーが決定されるルールに影響を与えている。

時間軸の配置をズラすだけでは処理のプライオリティー設定が行えなくなった場合に試す奥の手の対処法で、実質的にはシャッフルを行うようなものなので直接的な結果は想像出来ないが、タスクが特定のDSPに集中している場合に処理の配分先を変更出来る可能性がある。

LiveInputにTriggerTripletを実装する

ライヴ入力にTriggerTripletを実装したが、効果がイマイチだったので残響系のGranularDelayの出力にEGを追加した。　



所謂ゲートリヴァーブの亜種のようなものだが、好みな雰囲気に仕上がっている。

出来ればFilter系やDelay系にも機能の追加を行いたいところだが、既にDSPの分配がアウトっぽいので、この件はペンディング。

現状でも効果は十分に実感出来ているので、全てのアウトプットにこの手当を行うことは却って無粋なのかもしれない。

Main入力では、効果がイマイチで全く使うことのなかった「ベースラインに出力を同期させる機能」を実装していた部分をそのまま入れ替える形でTriggerTripletを導入している。



いまのところ機能が発動するスイッチはライヴ入力全て共通で行っているが、



使い難い場合は個別にオン・オフの設定を行うことになる。

再生できない場合、ダウンロードは🎵こちら

TripletTriggerを他のオブジェクトに展開する

パルス状のエンヴェロープを供給するTripletTriggerをリズム音源の一部に追加した。



ついでにRecCにもトリガーを移植した。当初は、サンプル再生オブジェクトの出力値を設定する箇所にEGを配置して直接駆動を試みたのだが、これが何故か失敗。　最終的にはより下流のミックスアウトにEGを組み込んでいる。



実験の結果、クリックノイズの発生はEnvelopeの立ち下がりに発生する傾向が強いことが判明しているが、立ち上がり側の時定数は数msでも問題はなさそう。

再生できない場合、ダウンロードは🎵こちら

BassSequencerの設定について

BassSequencerに実装したパルスっぽいフィルイン機能が、システム全体に行ったぱっつんノイズ対策の煽りで無効化されていることが発覚、EGの設定を修正することになった。



ノイズの発生を恐れてEGのGate信号を10msでスムージングしていたのがパルス状のトリガーには応答速度が間に合わなかった。　

今回は折衷案としてこれを5msに変更している。

StepPlaybackSamplerの設定について

StepPlaybackSamplerは録音したソースを16分割にスライスしてリズムに合わせたタイミングで各ピースを再生するオブジェクト。




これには短いパッセージを3ch記録出来るのだが、パラメーターの設定が複雑過ぎるのが問題で、特に !OneRecUnitAR * !MagR によって、再生ピースの尺の調整を行う部分の理解が遅れていた。

アイデアを具現化する過程で生じる齟齬をリアルタイムで操作が可能なホットパラメーターの追加によって「使える形」に合わせこむ作業を行うのだが、このパラメーターのスイートスポットがクリティカルな場合、試行錯誤がそのまま式という形で残ってしまい、それらの整理を怠った結果が今の混乱した情況を招いている。

録音回路にクリックノイズ除去用のディレイラインとEGを追加する

全録音回路の録音オブジェクトの手前に音声キャプチャーの開始／終了時に発生するクリックを除去するためのディレイラインとEnvelopeGeneratorを追加した。

録音開始のゲート信号のタイミングによって、入力信号が20msのエンヴェロープでミュートされる。

PanPot関連の構造をリファインする

Pan関連のオブジェクトをスクリプトベースな構造に変更した。



これは、オシレーター系オブジェクトをコントローラーとして扱った時の動作がイマイチ信用出来ないことがタイミング制御機構をリファインする過程で発覚したために行った改定で、、、



変更後は値の境界で発生するブチブチがなくなった模様。

クロック制御系のリファイン（続き）

今日は、不要なタスクを可能なかぎり排除する方向でオブジェクトをリファインする作業を始めているが、まずはサンプラーの制御信号を生成するオブジェクト内に展開していたGraphicalEnvelopeを取り除くことにした。



デューティーサイクルをほぼパルス状の信号が出力されるレベルに調整したが、サンプラーの同期に問題は発生しなかった。



midiClockの出力をモニターしたところ結果は上々で、

再生できない場合、ダウンロードは🎥こちら

120BPMの再生環境で信号を測定した結果、より正確なタイミングでクロックが出力されるようになった。

同期信号系の動作を確認する

今日はサンプル・プレイバックをコントロールする同期系の調整を行っているのだが、立ち上げ時の儀式をしくじると、Percussion音源を駆動するトリガーのタイミングが狂って、周期的に再生が行われないことが判明した。

不安定な再生情況を把握すべく、過去に表示系を設置していたようだが、



何故か非表示扱いになっていたので、これを修正して視認が行えるようにした。

今回の改装では、録音時のテンポを視認するためBPMに合わせてボックスタイプのGUIが点滅する機構を追加したものの、



動作の精度が悪く、対症療法としてToggleで信号を分周してエラーの発生率を下げる手当を行っているのだが、何れにしても視認性がいまひとつな状態なので、この箇所は今後の改良を検討しなければならない。

追記：

その後、動作の軽さを考慮してスクリプトベースでクロックを発生させるメトロノームを試作してみたが、パルスジェネレーターの動作が不安定なうえ、シーケンスをスタートさせるタイミングでリセットを掛けられなかった。　最終的には、同期信号によってタイミングのズレを補正しながらpulseTrainからクロックを生成する「録音機構に準じた仕組み」でシステムを構成しているが、反応が読み切れないVCSのタスク管理に関してプリミティヴなレベルで検討を行う必要を感じた。



今回の改装では他に暫定でmidiクロックを出力する機構を組み込んでいる。

再生できない場合、ダウンロードは🎥こちら

Timelineの改装を進める

FakeKeyboardのバグっぽい動きは、インターフェイスに付随する!keyTimbreというパラメーターがTimelineにリストアップされない「仕様」によって、存在そのものが認識されなかったことが原因だった。



要はグローバルコントローラーがリストアップされない仕様を忘れていたのだが、不可視な項目はなにかとトラブルの元になりそうなので、この辺りのルールの再確認を徹底した方がよい。



外部入力を選択した場合の!keyTimbreを削除して問題は解決した。



例の如く、過去に行った謎な配線の所為でラインの再構築が混乱させられてしまったが、RevPianoとGrainSyntheで共用していた音声駆動のソース元を、個別で切替られるようにデータラインの構造を変更した。

フィードバックループの接続が怪し気で修正を行ったGranularDelayの配線を試しに元に戻した(タスキ掛け→並列化→タスキ掛け)ところ、普通に動作したのが意外だった。



このオブジェクトは音の空白が生じることを防ぐ為にキャプチャーのタイミングを相互にずらした2つのディレイユニット配置し、その間にフィードバックループをタスキ掛けに繋いでリレーションを行っていたのだが、



トラブル発生時はこのフィードバックループが無効になって、本来得られていたReverb的な効果が消滅していた。

厳密にはオリジナルからフィードバック値を再設定しているので「元に戻した」とは言いきれないのだが、変更後のフィールは大きく変化した。
具体的には出音が安定サイドに振れて低域が強化された感じで、並列にフィードバックを返した場合と比較して強烈な倍音が発生する確率が低くなるようだ。

そもそもこれは同一である筈の信号処理回路の構成が微妙に変化してしまった結果発生した問題だが、コンパイラのクセと理解すればよいのだろうか、、、。

HeaveyTask版に合わせて、LightTaskヴァージョンのTimelineを更新している。



HeavyTaskな方に行った制御系の変更を移植しているのだが、RevPiano周りに行った機能強化の影響は予想していたよりも大きく、コンパイル行う優先順位を若干ではあるが変更する必要があった。

生楽器を中心に扱う場合は、原音がクリアに聴こえるこちらのTimelineを選択した方が良いかもしれない。

サブループの再生音声から音源をドライヴする仕掛けを造る

Granular Syntheのドライヴをサブループの再生音から行う機能を追加した。バックトラックのシーケンスをリアルタイムで作成することが目的。



録音したソースの再生方向を逆転出来るところがミソで、この機能によって演奏パターンにランダム性を付加できる。

FVC周りの改装を行うついでに、ReversePiano音源のドライヴをサブループから行えるようにした。



バスに打ち上げられた音程情報を36でmodulo後にtruncateし、36nn分のサンプル再生オブジェクトを駆動するトリガーを生成している。

再生ソースは生ピアノ（単音をサンプリングしたもの）の逆回転サウンドで、サブトラックに記録した演奏にピッチが追従する。

追記：

RevPianoのトリガーが発動する設定値に難があったので、これを従来型と同様に調整が可能な形に変更した。



ソースによって切り替わるトリガーの扱いを明確にするために、"removeUnits"で括るピッチデータをソース別に分割している。

以下、演奏によって機能の実例を示す。