2019年12月30日

LFO/PITCHBENDのThreshold 設定項目の改良

LFO/PITCHBEND が発動するスレッショルドポイントの設定を行うMode9の項目の切り替えを下側のポットで行えるように、インターフェイスを改良した。

Screen Shot 2019-12-29 at 17.37.07.png

Screen Shot 2019-12-29 at 17.46.12.png

同時に、上側ポットの長押しで行っていた項目の切り替えを廃止した。

Screen Shot 2019-12-29 at 17.47.58.png
posted by Yasuski at 07:25| LaVoixski

2019年12月29日

FrequencyDetectorの改装を行う

今日は、年内最後になるかもしれないプログラムの大改装を行っている。

ここ最近の試験運用で気になっていたのは、左手の分解能を「粗く」感じることで、実際のところはどうなのかをLEDのマーカーを使って調べてみると、本来12bit幅はある筈の変化量が高々10bit程度なことが判明、周波数ディテクタ関連の設定を根本的に考え直さなければならなくなった。

Screen Shot 2019-12-29 at 16.12.17.png

チューニングモードで左手側のダイナミックレンジ=聴感上の周波数変化を測ってみると、これが実質1Octに満たない状態で、なるほどこれは由々しきナローレンジだ。 周波数が低い方のレンジを稼げないのはFTMの設定の問題で、プリスケーラの分周率を上げることでディテクトが可能な最低周波数を拡張した。 

Screen Shot 2019-12-29 at 14.40.34.png

改装後は大凡12bitのダイナミックレンジを確保できたが、改変のついでにディテクター出力のオフセット値を現実的な領域まで狭めて、全体の変化量に合わせた。

Screen Shot 2019-12-29 at 14.34.15.png

Volumeカーヴの出力は専用のWavetableにアンテナからの復調信号のアップエッジをカウントしたレアデータを対応させて生成しているが、よりスムーズな変換を行うためにレアデータの方にも新たなLPFを噛ませることにした。

Screen Shot 2019-12-29 at 14.34.45.png

再起動後に謎な挙動を示すオフセットの設定不良は、ロータリーエンコーダでオフセットを調整してEEPROMに記録する際に、修正値にデフォルト値の加算を忘れていたことが原因だった。

Screen Shot 2019-12-29 at 14.37.54.png

暫定的に同じ値を割振っていたDetectorOutとWavetableのLPFを個別にチューンした。 特にDetectorOutの方は周波数が高くなる方向で音量が小さくなるように逆転した設定を行っているが故に、周波数の変動率はピアニッシモの方が大きくなる特徴があり、それに準じたLPFの帯域設定を行う必要があった。

その他、TransitionControlで行っていたモジュロ演算を簡略化して、構成をシンプルにしている。

Screen Shot 2019-12-29 at 14.35.19.png

改良の結果、グリッチは依然として発生しているが、発生域とレベルをそこそこ押さえ込むことが出来ている。
posted by Yasuski at 16:19| LaVoixski

2019年12月26日

RGBLEDをanalogWriteで制御する

pinが足りないTeensy4の不足分を補うために、LEDの発色をPWMでコントロールすることを思いついた。

Screen Shot 2019-12-26 at 5.36.13.png

予め発色を指定できるので、LEDの輝度がバラついた場合の対処が楽そうなところが良い。

Screen Shot 2019-12-26 at 5.06.40.png

setColorというサブルーチンを使って、RGBタイプのLEDを一括に制御する手法で、今まで個別に指定していたLEDの操作を簡単に行うことが出来る。

Screen Shot 2019-12-26 at 5.08.05.png

このように、LEDを制御する記述がシンプルに整理された。

Screen Shot 2019-12-26 at 5.08.55.png

予想される問題はPWMから発生するノイズだが、これは実験してみないと判らない。
posted by Yasuski at 05:38| LaVoixski

Teensy4.0にFLEXPWMを実装する

コンパイルが通るか通らないかという低いレベルの話ではあるが、トレーサーを仕掛けて情況を把握した結果、件のラインが悪さをしているようで、これらを排除すると形式的にはLoopに入ることが出来た。

Screen Shot 2019-12-25 at 14.03.33.png

この状態でコンパイルは通るのだが、何かがおかしい。

Screen Shot 2019-12-25 at 15.10.24.png

設定を記述する作法がイマイチ解らない。 とりあえず、マニュアルを愚直な形で解釈した結果がこうなった。多分これで間違いはない筈だ。

Screen Shot 2019-12-25 at 16.00.32.png

WEBにアップされている製作例を参考にいろいろと試行錯誤を繰り返したが、FreescaleとNXPではTimerのアーキテクチャが大きく異なるために、過去の経験則は通用しそうにない。 ということで、基本に立ち返って概念図を眺めることにした。

Screen Shot 2019-12-26 at 2.29.46.png

FLEXPWMでは入力に対して複数のタイミングでキャプチャが行えるようだが、外部から信号を入力する端子毎に1ユニットを接続しなければならない。Timerの状態を個別のトリガー入力でキャプチャする仕組みは同じだが、FreescaleのFTMとは全体の構造が大きく異っているようだ。

Screen Shot 2019-12-26 at 2.32.13.png

この図はキャプチャのタイミングマップで、トリガーエッジでキャプチャが発動するタイミングが良く判る。

つまり、FLEXPWM4_SM0STSで複数のキャプチャエッジのセレクトを行っている現状は間違いで、新たにFLEXPWM4_SM1STSを追加する必要がある。

Screen Shot 2019-12-26 at 2.13.43.png

入力のノイズを取り除くフィルターの設定項目を発見したので、これを追加。同時にインターラプトの設定も行っている。

Screen Shot 2019-12-26 at 2.13.33.png

IOMUXの設定はややこしいので再確認を行ったところ、

Screen Shot 2019-12-25 at 20.59.49.png

Screen Shot 2019-12-25 at 21.01.00.png

pinの配列は提示された2種類のなかから選別しなければならないことが判明。 この部分にも誤解があったので、修正を行うことになった。

Screen Shot 2019-12-26 at 3.13.34.png

なお、SIONを設定すればモード設定の必要はなく強制配置が可能なのだが、これに限らず重複する機能設定項目がマニュアルをざっと眺めただけでも少なからず存在するようで、素人にとってはさながら迷宮に迷い込んでしまった感がある。

Screen Shot 2019-12-26 at 5.00.28.png

コアの部分が共通なCortexMシリーズだが、ハードウエアに依存する部分は知識の共有が行えず、チップを乗り換える毎に新たな学習を強いられてしまう。 自分のように系統だった教育を受けていない独学者には少々荷が重い状況だが、結局は3000頁あまりの物量を誇るマニュアルを読み込むのが一番の近道なのだろう。

追記:

FrequencyDetectorの構造は稼働実績が全く無く、ハードウエアによる実証試験を行うまで全ては想像の域を出ないのだが、フラグクリアをこの場所で行うとデータがアウトプットされないのでは?という疑問が生じた。

Screen Shot 2019-12-27 at 4.50.59.png

GPTを使った製作例では、attatchInterruptVectorを使ってサブルーチンに飛び、そこで獲得した値を抽出した時にインターラプトのリセットを行っていたので、FLEXPWMを使用する場合もリセットはデータを抽出した後に行うのが正解だろう。 

ということで、リセット関連の記述を削除したが、ここでORされているRFの扱いがいまいちよく解っていない。

インターラプトに関連する疑問もあって、実験ではNVICを設定してしまうとこのサブルーチンから抜けられなくなってしまうのだが、これもMCU単独では正確なところは判らず、AudioClockを印加した状態で動作を判断する必要がある。

追記2:

マニュアルを読みなおしたところ、、、

81527996_2848818428481930_2278560586675519488_o.jpg

カウンターのフルスケールはVAL1に設定するようだ。

Screen Shot 2019-12-27 at 13.39.37.png

参考にした原典ではVAL2を読んでいるので、

WS002069.JPG

こちらも参照先をVAL0からVAL2に変更しておいた。

Screen Shot 2019-12-27 at 13.39.59.png
posted by Yasuski at 02:56| LaVoixski

2019年12月25日

Teensy4.0にMicroSDカードを接続する

当初は極性を間違えて焦ったが、なんとかMicroSDカードの接続を行うことができた。

IMG_9730.JPG

実験では、MicroSDカードからデータを読み出すルーチンの途中で読み出し不能となる問題が発生したが、原因はセットアップ・ルーチンの中に仕込んでいた周波数ディテクターのサブルーチンにあると判明、、、

Screen Shot 2019-12-25 at 11.16.48.png

コードの配置を変更したところ、とりあえずデータの読み出しを完璧に行うことが出来るようになった。

Screen Shot 2019-12-25 at 11.17.00.png

以下にSDcardからデータを受取ったレジスタの状態を示す。

Screen Shot 2019-12-25 at 10.56.55.png

Teensy3.6と比較して物凄い速さでデータが転送されていく。

Screen Shot 2019-12-25 at 10.57.13.png

4kを越える容量のデータアレイ群は、DMAMEMを使ってgroup2のメモリーバンクにデータをストアしている。

Screen Shot 2019-12-25 at 10.57.35.png

データの読み出しと共に、処理ステップを確認するためのRGBLEDによる表示を行っている。

Screen Shot 2019-12-25 at 10.57.46.png

データの読み出し終了後は、単体LEDによってセットアップルーチンのステップを確認している。

Screen Shot 2019-12-25 at 10.57.58.png

単体のLED はコンパイルのテストを行う過程で適当に追加したマーカーなので、今後配置などを改善する必要あり。

Screen Shot 2019-12-25 at 10.58.16.png

問題となった周波数ディテクタはハードウエア依存なパートで稼働実績が全く無い。これから実効性のある仕掛けを構築していくことになるが、前途多難な雰囲気がする。
posted by Yasuski at 11:03| LaVoixski

2019年12月24日

Teensy4,0にプログラムを移行する(継続中)

動作の保証は全くないが、なんとかコンパイルだけは通すことが出来た。

Screen Shot 2019-12-24 at 6.22.13.png

今回は、DMAMEMを使ってメモリー消費が大きなデータアレイ群をMemoryBank2にアサインすることで、MemoryBank1のオーバーフローを防ぐ手法を試した。

Screen Shot 2019-12-24 at 6.22.23.png

なお、SmallestCode以外のオプティマイズは受け付けられないようで、通常のFastestで行うとUSBの接続が死亡する形で動作不能に陥ってしまう。
posted by Yasuski at 06:33| LaVoixski

2019年12月20日

Linear Interpolation の実装を行う

AudioClock と比較して時間軸の精度が粗いFTMからのデータを線形補完するシステムの実装を完了した。

Screen Shot 2019-12-20 at 12.21.41.png

当初レジスタのデータ型にintegerを設定していたが、実験の結果、割り算の解が1以下になると補完が全く行われないことが判明、最終的にはデータ型をfloat_32に拡張し、

Screen Shot 2019-12-20 at 11.52.00.png

Screen Shot 2019-12-20 at 11.51.29.png

結果をuint16_tにキャストする方法に落ち着いた。

Screen Shot 2019-12-20 at 11.53.35.png

聴感上の印象ではあるが、従来の状態から大幅にグリッチ・ノイズを減衰できたようだ。



同様の処置を行ったPitch側のセンシングは低域・高域共に荒れた感じが無くなって、こちらの方は期待していたよりも御利益が大きかった。

posted by Yasuski at 17:25| LaVoixski

Volumeにinterpolationを導入する

InterpolationをVolume/Pitchに導入するための備忘録。

AudioClockとFTMのインターラプトはデータを更新する周期が大きく異なるが、周期の長いFTMがデータを更新するタイミングで音量に段差が発生し、これがノイズとして認識されている。

段差を解消する方法としては、最も簡単なリニア補完を考えている。 メソッドは、固定されたAudioClockのタイミングでFTMが更新する時間をカウントし、バッファーにストアした新旧データの差分をカウントしたステップ数で割ってAudioClockが1クロックあたりに補完する値を算出する。

具体的な手続きは、、、

まずAudioClockと連動したPitch/Volume用のTimerを設定。

Screen Shot 2019-12-20 at 11.52.51.png

Timer はFTM のインターラプト毎にレジスタにストア&リセットを掛ける。

同じタイミングでPitch /Volume の新旧データを更新した後、サブルーチンにジャンプ。

Screen Shot 2019-12-20 at 11.58.39.png

サブルーチンでは新旧データの差分をレジスタにストアしたTimer の値で除算して、AudioClock 1step 分の補完値を算出する。

Screen Shot 2019-12-20 at 11.59.07.png

Volume側は、Transitionの分だけ計算が複雑になっている。


posted by Yasuski at 08:53| LaVoixski

2019年12月19日

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

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

Screen Shot 2019-12-19 at 5.13.50.png

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


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

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

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

2019年12月17日

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

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

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

Screen Shot 2019-12-17 at 17.41.37.png

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

Screen Shot 2019-12-17 at 17.55.28.png

恐ろしいのはRevPianoで、

Screen Shot 2019-12-13 at 12.17.14.png

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

Screen Shot 2019-12-18 at 14.49.59.png

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

IMG_9720.JPG

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

Screen Shot 2019-12-18 at 14.47.58.png

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

IMG_9713.JPG

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

IMG_9725.JPG

以上の変更で、BPMの変更やTapによる短いループをマスターにする機能を選択した場合でも破綻は起こらなくなった。
posted by Yasuski at 19:52| Symbolic Sound Kyma

BassSyntheのMuteSwitch周りを改良する

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

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

Screen Shot 2019-12-17 at 2.54.24.png

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

Screen Shot 2019-12-17 at 2.24.40.png

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

Screen Shot 2019-12-17 at 2.54.15.png

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

今日のダイエット

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

Screen Shot 2019-12-16 at 22.52.46.png
posted by Yasuski at 01:59| Symbolic Sound Kyma

2019年12月15日

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

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

Screen Shot 2019-12-14 at 20.58.18.png

!MagC と !StepA(B) の比率でトリガーが発生する周期の倍率を決定する手法で解消している。
posted by Yasuski at 02:48| Symbolic Sound Kyma

2019年12月13日

FVCに大改装を行う

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

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

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

Screen Shot 2019-12-13 at 12.13.54.png

Screen Shot 2019-12-13 at 12.14.19.png

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

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

Screen Shot 2019-12-13 at 12.17.14.png

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

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

Screen Shot 2019-12-13 at 12.15.38.png

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

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

IMG_9711.JPG

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

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

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

IMG_9711.JPG
posted by Yasuski at 12:55| Symbolic Sound Kyma

2019年12月12日

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

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

Screen Shot 2019-12-12 at 4.48.56.png

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

Screen Shot 2019-12-12 at 4.49.41.png

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

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

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

Screen Shot 2019-12-12 at 7.28.41.png

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

Screen Shot 2019-12-12 at 8.06.29.png

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

Screen Shot 2019-12-12 at 9.16.14.png

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


追記:

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

Screen Shot 2019-12-13 at 0.05.32.png
posted by Yasuski at 04:57| Symbolic Sound Kyma

2019年12月11日

今日の小改装

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

Screen Shot 2019-12-11 at 5.36.52.png

Delay3系統と、、、

Screen Shot 2019-12-11 at 5.38.10.png

Screen Shot 2019-12-11 at 5.37.44.png

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

Screen Shot 2019-12-11 at 5.37.19.png

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

Screen Shot 2019-12-11 at 16.22.24.png

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

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

Screen Shot 2019-12-11 at 16.22.08.png

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

Screen Shot 2019-12-11 at 16.21.38.png

ステップ再生タイプのサンプラーからは既に該当するEGを撤去しているが、動作に支障はなかった。
posted by Yasuski at 02:54| Symbolic Sound Kyma

2019年12月09日

DSPの処理分配について

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



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

Screen Shot 2019-12-09 at 11.25.31.png

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

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

2019年12月08日

LiveInputにTriggerTripletを実装する

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

Screen Shot 2019-12-08 at 23.20.57.png

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

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

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

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

Screen Shot 2019-12-08 at 23.21.31.png

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

Screen Shot 2019-12-08 at 23.20.13.png

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



posted by Yasuski at 23:34| Symbolic Sound Kyma

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

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

Screen Shot 2019-12-08 at 14.37.19.png

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

Screen Shot 2019-12-08 at 18.57.08.png

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

posted by Yasuski at 18:58| Symbolic Sound Kyma

BassSequencerの設定について

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

Screen Shot 2019-12-07 at 22.24.49.png

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

今回は折衷案としてこれを5msに変更している。
posted by Yasuski at 00:01| Symbolic Sound Kyma