Skip to content

Development

odashi edited this page Nov 15, 2026 · 1 revision

Integralのビルド・検証・開発

Integral Wiki · README

ビルド、検証、配布、開発フローの手順をまとめています。ツールの固定版はscripts/ci-versions.sh、起動条件はワークフローを参照してください。

バージョン表示・タグ起動のリリース・Node.js 24対応Actionsは、PR #109の内容です。利用するリビジョンへの統合状況を確認してください。

ビルド

実行環境はAVX2・FMA3対応のx86_64 CPUと、XMM/YMM状態を保存・復元するOSを必要とします。Linux GNU版・Windows MSVC版とも、.cargo/config.tomlで+avx2,+fmaを有効にします。VST3のモジュール開始とFactory取得では、通常のRustコードへ入る前にCPUIDとXGETBVで検証し、非対応環境を拒否します。

Rust 1.95以上が必要です。LinuxではCリンカー、WindowsではVisual Studio Build Toolsの 「C++によるデスクトップ開発」とWindows SDKを導入してください。 GUIの依存クレートはCargoがcrates.ioから取得し、バージョンはCargo.lockで固定します。 LinuxでのGUI実行にはX11、libxkbcommon-x11、OpenGL/EGLのランタイムが必要です。 プラグイン本体のビルドにVST3 SDKは不要です。バンドル・ZIP生成にはPython 3とGitも使用します。

Linux:

sh scripts/build-vst3.sh

Windows(PowerShell):

rustup target add x86_64-pc-windows-msvc
python scripts/build-vst3.py

LinuxからWindows版を生成する場合:

LLVMのclang-clとlld-linkをPATHへ追加し、cargo-xwinを導入します。 確認した構成はcargo-xwin 0.23.1、LLVM 19.1.7、Windows SDK 10.0.26100、MSVC CRT 14.44.35220です。 cargo-xwinはMIT、LLVMはApache-2.0 WITH LLVM-exceptionで提供されています。 SDK・CRTはcargo-xwinがMicrosoftの配布元から取得・キャッシュし、Microsoftのライセンスが適用されます。

cargo install --locked cargo-xwin --version 0.23.1
rustup target add x86_64-pc-windows-msvc
python3 scripts/build-vst3.py --target x86_64-pc-windows-msvc

LinuxからWindowsターゲットを指定した場合、スクリプトはcargo xwin buildでビルドし、 通常のWindowsビルドと同じ配置・バージョン情報・ライセンス通知を持つZIPを生成します。 --targetを省略すると実行環境向けにビルドします。

生成物(Linux):

target/vst3/Integral.vst3/
└── Contents/
    ├── x86_64-linux/
    │   └── Integral.so
    └── Resources/
        ├── build-info.json
        └── Licenses/
            ├── LICENSE
            ├── COPYRIGHT
            ├── THIRD_PARTY_NOTICES.txt
            └── dependencies/  # 依存ライブラリ・付属フォントの通知とindex.json

Windowsではバイナリの位置が Contents/x86_64-win/Integral.vst3 になります。 target/dist/ にもバンドル全体を含むZIPを生成します。Windows版はCRTを静的リンクします。

ビルドスクリプトは最適化ビルドを行い、ホストが読み込めるバンドルを作成します。 開発用の共有ライブラリだけが必要な場合は cargo build --locked を使用します。

バージョン情報

ホストへ返す PClassInfo2.version は次の形式です。

  • 開発版: dev-<40桁のコミットID>。GitのHEADを使用します。
  • 正式リリース版: Cargo.toml の version に指定したSemantic Versioning(例: 0.1.0)。

cargo build --release の最適化指定だけでは正式リリース版になりません。 正式版は INTEGRAL_RELEASE_VERSION=v0.1.0 のようにタグ名を指定してビルドします。 先頭のvを除いた値がCargo.tomlと異なる場合、またはGitの作業ツリーに変更がある場合は失敗します。 v[0-9]*タグのpushでVST3 Buildを起動し、タグ名をこの環境変数へ渡します。

GUIのロゴ右側には指定文字列をそのまま表示します(例: v0.1.0)。未指定・空文字ならdevです。 build.rsがINTEGRAL_DISPLAY_VERSIONへ埋め込み、環境変数の変更時にはCargoが表示文字列を更新します。

Contents/Resources/build-info.json にホスト向けのversion、GUI用のdisplay_version、完全なコミットID、変更の有無、ターゲットを記録します。 ローカルの未コミット変更は dirty: true で識別し、CIでは変更のないチェックアウトだけを配布します。 Git情報のないソースからビルドする場合は、出典の完全なIDを INTEGRAL_COMMIT に指定してください。 Gitチェックアウトでこの値を指定した場合、HEADとの不一致は拒否します。

生成物と実験記録の保管

ビルド・検証の生成物はtarget/以下へ出力します。配布ZIPにはライセンス通知とビルド情報を含めます。 公開Wikiの現行資料はdocs/、過去の実験・障害調査はlogs/で管理します。保存構成と再現方法を参照してください。 比較記録には対象コミット、環境、条件、測定値、統計量を記載し、現在の製品仕様と区別します。新たな大容量音声や配布バイナリはWikiへ追加せず、適切な成果物保存先から参照します。

GUI素材と描画

金属パネルGUIの外観・実装・測定を参照してください。素材の生成プログラムはscripts/textures/、生成済みPNGとRGB/RGBAデータはsrc/editor/で管理します。プラグインは生成済みデータを埋め込みます。

リポジトリのルートで次のコマンドを実行すると、金属板・ロゴ・ノブ・LCD・ラバーボタンを再生成します。

python3 scripts/textures/generate-panel.py
python3 scripts/textures/generate-logo.py
python3 scripts/textures/generate-knob.py
python3 scripts/textures/generate-lcd.py
python3 scripts/textures/generate-button.py

生成器はPython標準ライブラリを使い、SVGロゴのラスタライズ時だけImageMagickのconvertを呼び出します。GUIの描画にはegui・egui_glow・baseviewを使います。LCDとボタンは96×40px、外周12pxを固定した9分割伸縮とし、ノブとロゴは物理ピクセル等倍で表示します。

描画は背景と前景の2枚の固定面へ分けます。背景には金属板・ロゴ・彫り込み線・ノブ本体・目盛り・ラベル、前景にはOff表示の50%合成・LCD・ボタン・メーターの消灯面を保持します。配置・エフェクト種類・Off状態・フォント画像の大きさが変わると固定面を更新します。ノブの針と発光弧は整数tick・位置・表示倍率ごとにメッシュを再利用し、選択値・メーターの点灯・押下表示・操作中のオーバーレイを動的に重ねます。

固定面は同じOpenGLコンテキスト内のFBOでRGBA8画像へ描き、画像を再利用します。FBOを利用できない場合は同じ位置へ固定メッシュを描きます。GL資源の作成・更新・解放はUIスレッドで専用コンテキストを有効にした範囲へ限定し、FBOの描画先を戻してから画面へ描画します。Windowsでは処理後にホストのコンテキストを復元し、画面を閉じる際はFBO、Painterが所有する画像の順に解放します。

検証

Rust側のレイアウト・識別子・参照管理のテストと静的解析:

rustup component add rustfmt clippy
cargo fmt --check
cargo test --locked
cargo clippy --locked --all-targets -- -D warnings

ABIを変更した場合は、公式VST3 SDKのヘッダを用いる検証も実施します。 公式VST3開発ドキュメント からSDKの取得方法を確認し、 pluginterfaces を含む展開先を指定してください。C++17対応コンパイラーも必要です。

export VST3_SDK_DIR=/path/to/vst3-sdk
sh scripts/check-abi.sh

Windowsでは「x64 Native Tools Command Prompt for VS」から次を実行します。

set VST3_SDK_DIR=C:\path\to\vst3-sdk
python scripts/check-abi.py

LinuxのGUI検証には入力注入用のlibXtst.so.6とカーソル検証用のlibXfixes.so.3も必要です。 GUIの表示・クリックも検証する場合は python scripts/check-abi.py --gui を使用します。 LinuxではABIテストのコンパイルに libx11-dev が必要です。画面のない環境では次のように実行できます。

sudo apt-get install libx11-dev libxtst6 libxfixes3 libxkbcommon-x11-0 libgl1-mesa-dri libegl1 xvfb xauth
LIBGL_ALWAYS_SOFTWARE=1 xvfb-run -a -s "-screen 0 1920x1080x24" python3 scripts/check-abi.py --gui

WindowsのGUI検証にはOpenGL対応ドライバーが必要です。ソフトウェア描画では固定版のMesaをABIテスト実行ファイルの隣に配置します。 GUIテストは表示・クリック・ノブの上下ドラッグ・カーソルの非表示と復帰・UIスレッドでの標準編集通知・保存復元・フォーカス喪失・操作中の終了と再表示を確認します。

GUI全体(1076×768 px)を画面内に収めるため、GUI検証はLinux・Windowsとも1920×1080 pxで実行します。Windowsでは検証前にPowerShellで次を実行します。

Set-DisplayResolution -Width 1920 -Height 1080 -Force
Get-DisplayResolution

Windowsの色検査に用いるGetPixelは、クリッピング範囲外でCLR_INVALIDを返します。GitHubのWindowsランナーにおける解像度設定とSet-DisplayResolutionを参照してください。

GUIテストは描画状態・カーソル復帰・編集通知を確認して次の操作へ進みます。

この検証はSDKのインターフェースで共有ライブラリをロードし、バージョン・ID・戻り値、100回のインスタンス生成・解放、 複数のブロック長、32/64ビットの発音・消音、音程変更・再発音での位相継承、 イベントのサンプル位置とノート照合、バッファ境界、同一バッファを指す出力、停止・再開とフラッシュを確認します。 パラメーターの列挙・表示・値変換、変更時刻と位相を含む実際の出力サンプル、 停止中のパラメーターフラッシュ、IBStreamの部分読み書き・保存復元・不正データの拒否も検査します。 音声テストは44.1 / 48 / 96 kHzとリアルタイム・プリフェッチ・オフラインモードを含みます。 検証用C++コードはプラグインにリンクされません。

公式Validatorのビルド・実行には、完全なVST3 SDKとCMake 3.25以上が必要です。

cmake -S "$VST3_SDK_DIR" -B target/vst3-sdk \
    -DCMAKE_BUILD_TYPE=Release \
    -DSMTG_ENABLE_VSTGUI_SUPPORT=OFF \
    -DSMTG_ENABLE_VST3_PLUGIN_EXAMPLES=OFF \
    -DSMTG_ENABLE_VST3_HOSTING_EXAMPLES=OFF \
    -DSMTG_CREATE_PLUGIN_LINK=OFF
cmake --build target/vst3-sdk --config Release --target validator --parallel 4
sh scripts/build-vst3.sh
target/vst3-sdk/bin/Release/validator target/vst3/Integral.vst3

Linuxでの確認済み環境: Linux x86_64、Rust 1.95.0 / 1.99.1、GCC 12.2、VST3 SDK 3.8.1 (インターフェース定義も3.8.1)。Rustテスト、ABI検証、Validatorが成功しています。 参照した公式SDKヘッダのライセンスはMITです。出典とライセンス全文は THIRD_PARTY_NOTICES.txt を参照してください。 FL Studioで発音とGUI操作の動作報告があります。 GUIの自動検証にはLinuxのXvfbとMesaを使用します。 通常演奏・連続操作41ケースの標準性能回帰スイートは、検証用Python環境を準備し、scripts/bench-standard.py --before <変更前worktree> --after <変更後worktree>で実行します。ビルドは比較する各ツリーのCPU命令設定を使用し、借用型へのAPI差だけを同一ハーネスへ適応します。実際のハーネスと設定は測定情報へ記録します。無作為化ブロックによる対応比較・統計検定とDSP単体の測定手順はbenchmarks/README.md、比較実験の結果はWikiにまとめています。

PRのテスト用ZIP

配布バンドルが必要な場合だけ、VST3 Buildを手動起動し、PRの先頭ブランチとPR番号を指定します。Linux版とWindows版をビルドし、ライセンス通知とビルド情報を含むバンドルをGitHub ActionsのArtifactsへ保存します。実行サマリーのダウンロードリンクまたはArtifactsからZIPを取得してください。保持期間は14日です。

VST3 Buildは通常のRust CIと独立しています。PR検証からは起動せず、バンドル生成の成否をマージ条件に使用しません。PRのbase・先頭コミット・ブランチは生成前に照合します。

例: Integral-windows-x86_64-pr2-<40桁のコミットID>.zip

PRでは先頭コミットを明示的にチェックアウトします。ZIP名・プラグインの開発版バージョン・ build-info.json は同じコミットを指します。ZIPを展開すると Integral.vst3 が得られます。 ダウンロードにはGitHubへのログインとリポジトリの読み取り権限が必要です。

リリース

Cargo.tomlのバージョンを更新してmainへ統合したコミットに、対応するv[0-9]*タグを付けてpushします。 たとえばCargo.tomlが0.1.0なら、次のタグを使います。

git tag v0.1.0
git push origin v0.1.0

VST3 Buildがタグのコミットをチェックアウトし、 Linux x86_64とWindows x86_64の配布ZIPを生成します。両方のビルドが成功し、ZIPが2つ揃った後にGitHub Releaseを公開します。 ReleaseのタイトルとGUIの表示はタグ名とし、ホスト向けバージョンは先頭のvを除いたSemantic Versioningです。 例ではIntegral-linux-x86_64-0.1.0.zipとIntegral-windows-x86_64-0.1.0.zipが添付されます。

リリースノートはgh release create --generate-notesで自動生成します。 --verify-tagで既存タグを確認し、公開ジョブだけにcontents: writeと成果物取得用のactions: readを付与します。 手動起動のworkflow_dispatchでは配布用Artifactを生成します。Releaseの作成はタグpushで行います。

開発フロー

trunk-based developmentを採用し、mainを唯一のトランク・統合先とします。 最新のorigin/mainから目的ごとに短命な作業ブランチを作り、単独で検証・マージできる小さなPRを 必ずmainへ送ります。作業中はmainの変更をこまめに取り込みます。 依存する後続作業は先行PRのマージ後に最新のorigin/mainから開始し、マージ済みブランチは再利用しません。

git fetch origin
git switch -c feat/change-name origin/main
# 変更・検証・コミット
git push -u origin HEAD
gh pr create --base main

PRのマージ先・先頭コミット・先頭ブランチをRust CIのPR targetで検査します。 プロジェクトのマージ条件として、mainへのマージにはGitHub ActionsによるPR targetとCI resultの成功、および最新のmainの取り込みが必要です。管理者もこのCI条件を満たす運用とします。 先頭コミットを更新した場合は、更新後のコミットでCIを手動実行してください。 マージ方法はsquashとし、マージ後は作業ブランチを削除します。

Rust CI

Rust CIはworkflow_dispatchで手動実行します。

ActionsのRust CIを開き、「Run workflow」でPRの先頭ブランチとpr_numberを指定します。

# 明示的に実行する場合、PRの先頭ブランチとPR番号を指定する。
gh workflow run rust.yml --ref feat/change-name -f pr_number=123
# バンドル生成は必要な場合だけ別途起動する。
gh workflow run vst3.yml --ref feat/change-name -f pr_number=123
# タグを指定して配布用Artifactだけを生成する場合。
gh workflow run vst3.yml --ref v0.1.0

Rust CIはpush・PR作成/更新・コメント・タグ作成・定期実行では起動しません。リリース用タグのpushは、上記のVST3 Buildを起動します。 同じブランチで再度起動すると、進行中の古いRust CIをキャンセルして最新の実行を優先します。

現在の.github/workflows/rust.ymlでは以下を検証します。 Linux x86_64とWindows x86_64のランナーを使用します。

ジョブ 内容
PR target open PR・マージ先main・先頭コミット・先頭ブランチを照合
Static analysis Linux/Windowsで警告をエラーにするClippy。Linuxでビルド情報のPython回帰テスト・rustfmt・ドキュメント生成
Test MSRV(Rust 1.95.0)/最新stableのtest(debug)でLinux/Windowsの全ケースを実行し、releaseはLinuxで実行する6組(全target・全feature)
Coverage RustテストのLCOVレポートを生成・保存
Dependency audit cargo-denyで脆弱性・ライセンス・依存元・依存バージョンを監査
CI result PR対象の照合とすべての検証ジョブの成功を確認

PR対象の検査・テスト・静的解析・Coverage・監査は並列に開始します。CI resultは全ジョブを待ってから結果を集約します。 テスト・解析ジョブは読み取り専用のリポジトリ権限で動作します。PR targetとCI resultは結果通知用のstatuses: writeを持ち、対象コミットのstatusへ開始時のpendingと終了結果を通知します。再実行時もpendingへ戻し、前回の成功で実行中の検査を通過させません。全検査の成功時だけCI resultを成功とし、失敗・スキップ・キャンセルでは成功にしません。 成果物は14日間保持します。 通常PRのCIからMiri・SDKによるABI検証・GUI検証・Validatorを除外します。必要な変更では、このページのローカル検証手順で実行します。 テストとCIの実行時間は可能な限り短く保ちます。並列実行とキャッシュを使用し、不要な重複処理を避けます。walltimeを合否条件にせず、Rust CI・VST3 Buildともワークフロー独自の経過時間制限やtimeout-minutesを設定しません。 現時点ではカバレッジ率の最低値は設けていません。

Rust CIとVST3 Buildは、Node.js 24を使用するGitHub公式のactions/checkout v7.0.1、actions/cache v6.1.0(MIT)、actions/upload-artifact v7.0.2をコミットSHAで固定しています。 Rust CIのTestと、独立したVST3 Buildのbundleでは、Cargoの取得済み依存とビルド結果をactions/cacheで再利用します。 キャッシュはOS・ジョブ・Rustコンパイラー・Cargo.lock・ビルド設定ごとに分け、Testではtest/releaseプロファイルもキーへ含めます。 Linuxのcargo-denyとcargo-llvm-covは、公式リリースのビルド済みx86_64 muslバイナリを取得します。バージョンとSHA-256をscripts/ci-versions.shで固定し、検証に成功した実行ファイルだけを${CARGO_HOME:-$HOME/.cargo}/binへ導入します。初回からソースのコンパイルは不要です。 依存変更時も同じコンパイラーのキャッシュから再利用できる分を復元し、Cargoが変更分を再ビルドします。 初回やコンパイラー更新時にはキャッシュ生成が必要です。CIではincrementalを無効にしてキャッシュ容量を抑え、 対象コミットをINTEGRAL_COMMITでも明示して古いバージョン情報の再利用を防ぎます。 独立したcargo checkはテスト・ビルドと重複するため実行しません。 テストジョブだけでCARGO_PROFILE_DEV_DEBUG=0・CARGO_PROFILE_TEST_DEBUG=0を指定し、デバッグ情報を生成しません。testプロファイルのdebug assertionsと整数overflow checksは有効です。releaseの製品ビルドは独立したVST3 Buildへ集約します。テストとバンドルのstable導入はminimalプロファイルとし、Clippyは別のStatic analysisジョブで実行します。

CIと同じRust用ツールをローカルへ一括インストールするには、rustup導入済みの環境で次を実行します。 stableの更新、MSRV・nightlyの追加、rustfmt・Clippy・LLVMツール・Miri・cargo-deny・cargo-llvm-covの導入を行います。 Linuxのビルド済みツールの導入にはcurl・tar・sha256sum・installを使用します。ダウンロードは最大60秒、ハッシュ不一致では既存の実行ファイルを置き換えずに停止します。

sh scripts/install-ci-tools.sh

追加ツールとnightlyのバージョン、検証用SDKのリビジョンは scripts/ci-versions.sh で管理します。 更新時はCI全体を再検証してください。SDK・CMake・C++コンパイラーは上記のVST3検証手順で別途準備します。

ワークフローの構文はactionlintで検証できます。手動起動の仕様はGitHub Actionsの公式資料、必須チェックの設定はルールセットの公式資料を参照してください。手動CIの結果通知にはcommit status APIを使用します。

検証のローカル実行例:

. scripts/ci-versions.sh
bash scripts/check-miri.sh
cargo +stable deny --locked check
mkdir -p target/coverage
cargo +stable llvm-cov --locked --workspace --all-features --lcov --output-path target/coverage/lcov.info

Miriでは数学関数へのランダムな追加丸めを無効にし、メモリ安全性の検査を有効にします。 対象はルートのABIテスト、パラメーターの保存・復元と変換、編集通知キュー、および数値変換・SIMDの境界テストです。 ホストイベントのテストはMiriでも実際のバッファを確保して発音・再初期化を検査し、サンプルレートの全組合せは通常のdebug/releaseテストで実行します。 長時間の音声・周波数応答・全設定の数値走査は通常のdebug/releaseテストで検証します。 音声の全組合せ・実効値の照合は通常テストで行い、Miriでは各コンポーネントの境界、 不正入力、状態遷移、ABIと最大設定の系列処理を検証します。

GUI・ウィンドウ・描画・フォントの依存ライセンスは deny.toml で監査します。 依存を追加する際は、利用条件と通知ファイルを確認して許可リストも更新してください。本体の配布ライセンスはこの設定では決定しません。

構成

  • build.rs: Gitコミットと正式版指定からバージョン・ビルド情報を生成。
  • src/abi.rs: 必要なABI型、OS別のID表現・戻り値、vtable定義。
  • src/lib.rs: モジュールの公開関数とファクトリー。
  • src/cpu.rs: AVX2・FMAとOSの状態保存対応を検証する起動入口。
  • src/plugin/programs.rs: VST3のルートユニットと内蔵プログラム一覧。
  • src/plugin.rs: インスタンス、バス、イベント・パラメーター処理、音声出力、Controller。
  • src/gui.rs: VST3画面の直接実装とホストへの編集通知。
  • src/editor.rs: カテゴリ別ノブ・ドロップダウンの入力とegui/OpenGL描画。GUIの構成も参照。
  • src/editor/fixed.rs / surfaces.rs: 固定面の記録・更新とFBO、固定メッシュへのフォールバック。
  • src/editor/indicator.rs: ノブの針・発光弧のメッシュ再利用。
  • src/editor/lcd.rs / skin.rs: LCDの選択欄、ラバーボタン、メーター、生成素材の9分割描画。
  • src/editor/edits.rs / pointer.rs / gl_context.rs: 編集通知キュー、OS別のカーソル操作、OpenGLコンテキストの保存・復元。
  • scripts/textures/: 金属板・ロゴ・ノブ・LCD・ボタンの素材生成。SVGロゴの原版はartwork/。
  • src/host.rs: UIスレッドに限定したホスト参照管理。
  • src/parameters.rs: 全パラメーターの選択肢・単位・値変換、VST3変更キューとIBStreamの読み書き。
  • src/volume.rs: 生波形の実効値補正・ユニゾン合成・Vol・定位。
  • src/oscillator.rs: 定常入力 OscillatorInput と内部状態 OscillatorState を分離した5波形オシレータ。
  • src/envelope.rs: 音量とカットオフで共用する正規化AHDSR計算と経過時間・再トリガー管理。
  • src/filter.rs: TPT SVFの3出力と、フィルタタイプによる出力選択・多段化。
  • src/chorus.rs: 左右の可変遅延・独立LFO・帰還を持つChorus/Flanger。
  • src/reverb.rs: 8線のHouseholder FDNと帰還LPF。
  • src/delay.rs: テンポ同期ステレオディレイと読出し位置のクロスフェード。
  • src/compressor.rs: 左右ピーク連動のsoft knee・Attack/ReleaseとWet/Dry混合。
  • src/phaser.rs: 6段正規化ラティスallpass、共通LFOと帰還によるPhaser。
  • src/effects.rs: 3スロットの直列処理、個別のDry/Mix・切り替え、全体の固定遅延。
  • src/distortion.rs: プリゲイン・クリップ・2階ADAA。src/distortion/はSoft用の原始関数と共有テーブル。
  • src/eq.rs: TPT SVFによるLow shelf・Peak・High shelfの3帯域EQ。
  • src/limiter.rs: 5 ms先読み・100 ms Release・左右連動の固定シーリングと純遅延。
  • src/synth.rs: Voiceの循環割り当て・共通の定位係数と、全Voice加算 → Effector 1 → 2 → 3 → EQ → Limiter → Master Volumeの処理パイプライン。
  • src/voice.rs: Voiceごとのノート照合と3発振器加算 → 共通音量AHDSR → ステレオFilterの処理パイプライン。
  • src/float_mode.rs: 音声処理中の非正規化数処理モードの保存・切り替え・復元。
  • src/random.rs: 位相とNoiseで共用するxoshiro256+乱数生成器。
  • src/oscillator_tables.rs: Detune倍率と四半周期正弦波の固定テーブル。
  • src/oscillator/adaa.rs: 位相変調の2階ADAA。adaa_data.rsとf2.binは共有の原始関数データ。
  • src/oscillator/wavetable.rs: 周期波の帯域選択と補間。wavetable.bin・wavetable_data.rsは生成済みの係数と帯域情報、reference.rsは回帰試験用のFourier級数。
  • src/tests.rs: Rust側のABIレイアウトと参照管理のテスト。各コンポーネントの回帰テストは各モジュール内に配置。
  • benchmarks/: 継続利用するDSPの速度測定。
  • tests/gui-smoke.h: 埋め込み画面とマウス操作の検証専用コード。
  • tests/gui-reentry.h: Windowsの描画・タイマー再入を再現する回帰試験。
  • scripts/bundle-licenses.py: 対象OSの依存ライブラリと付属フォントの通知収集。
  • tests/abi-smoke.cpp: 公式SDKの型を使う独立したABI検証。
  • scripts/build-vst3.py / scripts/check-abi.py: Linux/Windows共通のバンドル・ZIP生成とABI検証。
  • tests/build-metadata.py: コミット変更時の再ビルド、開発版・正式版の切り替え、出典検証。
  • .github/workflows/rust.yml: PR対象の照合とRustのテスト・静的解析・依存監査・カバレッジ。
  • .github/workflows/vst3.yml: 配布バンドルの生成とタグリリース。
  • scripts/install-ci-tools.sh: CI用Rustツールの一括インストーラー。
  • scripts/ci-versions.sh: CI用ツールと検証SDKの固定バージョン。
  • deny.toml: 依存関係の監査ポリシー。

過去のCI障害、待機条件、実行時間の比較は調査ログを参照してください。

Clone this wiki locally