2023-12-30

PCB設計を試した記録

DIYしやすいことで有名なギター用エフェクターのFuzz Factoryを自前のPCBを使って自作した。PCB設計してみたかったので。

作るもの

Fuzz Factory。よかった点は部品が少ない分簡単だったこと。有名なFuzzには割と当てはまる。また回路が有名でオンライン上に見つけられること。悪かった点は、ゲルマニウムトランジスタを使ったものとシリコントランジスタを使ったものがあり、電子回路をわかっていない自分にとって紛らわしかった。

PCB設計に使ったソフト

KiCad。無料のを選ぶならこれが一番人気そう。ソフトそのものを選ぶことより使うバージョンを選ぶ方が大事そう。バージョンが変わると使える部品（の名前？）や操作が割と違う。慣れた人には問題なさそうだけどその辺のチュートリアルを追う時に混乱した。

方針

ベストプラクティスを覚えるのは時間がかかりそうだったので、とにかくパッとやること。ソフトウェアならforループ知らないから全部whileでやるくらいの気合い。

KiCadを学ぶために見た資料

公式サイト: https://docs.kicad.org/
YouTube:
- https://www.youtube.com/watch?v=sEGyNfBuPig
自作エフェクターをされてる方のブログ:

Fuzz Factoryに関する資料

キットの説明書にいろいろ役にたつ情報が見つかることが多かった。例えば最後のリンクには基板のみ完成した段階でのテストの方法が載っている。

ざっくりKiCad操作の流れ

巷の回路図をKiCad常に書き写す

KiCadには現実のパーツの情報を集めたライブラリが含まれているので、回路上の部品を現実の部品に割り当てる。ただものによってはライブラリにカバーされていないのでそういう場合は自分でパーツの寸法とかの情報を作らないといけない。今回はそれを避けたかったのでライブラリにある部品のみを使って設計をした(可変抵抗はこの影響を大きく受けた。ライブラリにあり、かつ実際に買うことのできるものを探すのが大変だった。めんどくさいので次からは可変抵抗は基板に含めないようにするかも)

"#"	"Reference"	"Qty"	"Value"	"Footprint"	"DNP"
"1"	"C1	C3	C4"	"3"	"10uf" \| "Capacitor_THT:CP_Radial_D5.0mm_P2.50mm" \| ""
"2"	"C2"	"1"	"100nf"	"Capacitor_THT:C_Rect_L7.0mm_W2.5mm_P5.00mm"	""
"3"	"Comp1	Drive1	Gate1"	"3"	"10KB" \| "Potentiometer_THT:Potentiometer_Alps_RK097_Single_Horizontal" \| ""
"4"	"J1"	"1"	"IN"	"TestPoint:TestPoint_THTPad_D2.5mm_Drill1.2mm"	""
"5"	"J2"	"1"	"OUT"	"TestPoint:TestPoint_THTPad_D2.5mm_Drill1.2mm"	""
"6"	"J3"	"1"	"VCC"	"TestPoint:TestPoint_THTPad_D2.5mm_Drill1.2mm"	""
"7"	"Q1"	"1"	"2N3904"	"Package_TO_SOT_THT:TO-92_Inline"	""
"8"	"Q2	Q3"	"2"	"2N3906"	"Package_TO_SOT_THT:TO-92_Inline" \| ""
"9"	"R1	R6"	"2"	"220k"	"Resistor_THT:R_Axial_DIN0207_L6.3mm_D2.5mm_P7.62mm_Horizontal" \| ""
"10"	"R2"	"1"	"10k"	"Resistor_THT:R_Axial_DIN0207_L6.3mm_D2.5mm_P7.62mm_Horizontal"	""
"11"	"R3"	"1"	"47k"	"Resistor_THT:R_Axial_DIN0207_L6.3mm_D2.5mm_P7.62mm_Horizontal"	""
"12"	"R4"	"1"	"470"	"Resistor_THT:R_Axial_DIN0207_L6.3mm_D2.5mm_P7.62mm_Horizontal"	""
"13"	"R5"	"1"	"5.1k"	"Resistor_THT:R_Axial_DIN0207_L6.3mm_D2.5mm_P7.62mm_Horizontal"	""
"14"	"Stability1	Volume1"	"2"	"5KB"	"Potentiometer_THT:Potentiometer_Alps_RK097_Single_Horizontal" \| ""

PCBを設計する。割り当てた部品の情報を元にKiCadが設計をサポートしてくれる

基板の発注に使える形式にデータをエクスポートする

基板発注

無難な会社を選ぶ方針で探した。JLCPCBが人気な模様。

基板データのエクスポート: https://jlcpcb.com/help/article/16-How-to-generate-Gerber-and-Drill-files-in-KiCad-6

部品の購入

今回はBanzai Musicを使った。2023年時点でFuzz Factoryで使われている形の可変抵抗がイギリスから買えるほぼ唯一の店っだった気がする。 Mouserにもあった気がするけど使わなかった理由は忘れた。

組み立て

ケースやスイッチはサボり。

ハマったところ

YouTubeに従って基板データのエクスポートをしたもののJLCPCBにフォーマットが違うと怒られてしまった。JLCPCBのサイトに従ってやり直したら通った。
組み立ててから音が出なかった。一部の可変抵抗が届いていないためAmazonでブレッドボード用のを買って半田付けしたところ壊してしまってたらしい。この動画がトラブルシューティングに役に立った。

2022-07-30

何もしてないのにAppleのNotarizationがCIの中で失敗するようになった

結論、何もしてないわけではなかった (Apple IDのパスワード変更が原因だった)。

macOS 10.15以降、基本的に配布するアプリはnotarizeされている必要がある。

Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized.

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

普段自分はGitHub Actions中でgonを使ってnotarizationをやってるが、ある日 "The auth server returned a bad status code." というエラーでCIが失敗した。

Run gon -log-level=debug -log-json ./gon.json
==> 🍎  Notarizing...
    Path: ./build/src/Os251_artefacts/Release/installer/build/signed/OS-251.pkg
    Submitting file for notarization...
{"@level":"info","@message":"submitting file for notarization","@module":"notarize","@timestamp":"2022-07-29T23:35:06.644900Z","command_args":["xcrun","altool","--notarize-app","--primary-bundle-id","onsenaudio.OS-251","-u","***","-p","@env:AC_PASSWORD","-f","./build/src/Os251_artefacts/Release/installer/build/signed/OS-251.pkg","--output-format","xml"],"command_path":"/usr/bin/xcrun","file":"./build/src/Os251_artefacts/Release/installer/build/signed/OS-251.pkg"}
{"@level":"info","@message":"notarization submission complete","@module":"notarize","@timestamp":"2022-07-29T23:35:09.103667Z","err":"exit status 1","output":"\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003c!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\"\u003e\n\u003cplist version=\"1.0\"\u003e\n\u003cdict\u003e\n\t\u003ckey\u003eos-version\u003c/key\u003e\n\t\u003cstring\u003e11.6.8\u003c/string\u003e\n\t\u003ckey\u003eproduct-errors\u003c/key\u003e\n\t\u003carray\u003e\n\t\t\u003cdict\u003e\n\t\t\t\u003ckey\u003ecode\u003c/key\u003e\n\t\t\t\u003cinteger\u003e-1011\u003c/integer\u003e\n\t\t\t\u003ckey\u003emessage\u003c/key\u003e\n\t\t\t\u003cstring\u003eUnable to upload your app for notarization.\u003c/string\u003e\n\t\t\t\u003ckey\u003euserInfo\u003c/key\u003e\n\t\t\t\u003cdict\u003e\n\t\t\t\t\u003ckey\u003eNSLocalizedDescription\u003c/key\u003e\n\t\t\t\t\u003cstring\u003eUnable to upload your app for notarization.\u003c/string\u003e\n\t\t\t\t\u003ckey\u003eNSLocalizedFailureReason\u003c/key\u003e\n\t\t\t\t\u003cstring\u003eFailed to get authorization for username '***' and password. (\n    \"Error Domain=NSCocoaErrorDomain Code=0 \\\"Status code: 0\\\" UserInfo={NSLocalizedDescription=Status code: 0, NSLocalizedFailureReason=The auth server returned a bad status code.}\"\n)\u003c/string\u003e\n\t\t\t\u003c/dict\u003e\n\t\t\u003c/dict\u003e\n\t\u003c/array\u003e\n\t\u003ckey\u003etool-path\u003c/key\u003e\n\t\u003cstring\u003e/Applications/Xcode_13.2.1.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/Frameworks/AppStoreService.framework\u003c/string\u003e\n\t\u003ckey\u003etool-version\u003c/key\u003e\n\t\u003cstring\u003e4.071.1221\u003c/string\u003e\n\u003c/dict\u003e\n\u003c/plist\u003e\n\n\n"}
    Error notarizing

❗️ Error notarizing:

1 error occurred:
    * 1 error occurred:
    * Unable to upload your app for notarization. (-1011)

調べてみると、Appleのページに

主要 Apple ID のパスワードを変更またはリセットすると、アカウントを保護するため、App 用パスワードもすべて自動的に消去されます。引き続き使いたい App がある場合は、その App 用のパスワードをあらためて作成する必要があります。

と書いてる。言われた通りに同ページに書かれたApp用のパスワードを作成しなおして、それをGitHub Actionsの設定に反映(gonの文脈ではAC_PASSWORDの値を更新)したら、CIが再び成功するようになった。

2021-12-09

JUCEアプリケーションのベンチマーク測定

JUCEでオーディオのアプリケーション・プラグインを作るとき、その性能が大事になってくるケースも多いかと思います。そこでGoogle Benchmarkを使ったベンチマークの測定が可能なJUCEプロジェクトをCMakeを使って作ります。

今回のリポジトリはこちら。

今回はプロジェクトの設定にあたって

巷にあるテンプレートリポジトリに頼らずやる
最小限の設定にして、できるだけシンプルにする

という方針でやります。

事前に用意するもの

git環境
CMake (v3.15以上)
C++コンパイラ (gcc, clang, MSVCなど。Windowsの場合はPowershellでの操作を想定してます。)

参考までに最終コードの動作確認は - macOS 12.0 + clang 13.0.0 - ubuntu 21.10 + gcc 11.2.0 - Windows 10 + Visual Stduio 2019のMSVC

で行いました。

リポジトリにJUCEの追加（ダウンロード）

git submoduleを使ってJUCEのリポジトリをサブモジュールとしてlib/JUCEディレクトリに追加します。

# プロジェクトルート (.gitファイルがあるフォルダ) にcdコマンドで事前に移動してください

$ git submodule add https://github.com/juce-framework/JUCE lib/JUCE

これでJCUEのmasterブランチが追加されますが、より安定しているリリースバージョン(今回は6.1.2)を使います。

$ cd lib/JUCE
$ git checkout 6.1.2
# "HEAD is now at 46ea87973 JUCE version 6.1.2"と表示されるはず。

ここまでの変更を一旦コミットします。

$ cd ../../ # プロジェクトルートに戻る
$ git add .
$ git commit -m "Add JUCE 6.1.2"

これでサブモジュールの追加は完了です。

ここまでのコミット

アプリ・プラグイン本体のコードテンプレートの生成

JuceにはProjucerというツールが用意されていて JUCEアプリケーション（ベンチマークではなく本体）の骨組みを簡単に生成できます。今回はVST3などのオーディオプラグインを作ります。

Projucerの用意

./lib/JUCE/README.md (要するJUCEリポジトリのREADME.md)に従ってProjucerをビルドをします。

$ cd lib/JUCE # サブモジュールとして追加したJUCEのディレクトリに移動。
$ cmake . -B cmake-build -DCMAKE_BUILD_TYPE=Release -DJUCE_BUILD_EXTRAS=ON # Configureする
$ cmake --build cmake-build --config Release --target Projucer # JUCEプロジェクト生成アプリをビルド

.lib/JUCE/cmake-build/extras/Projucer/Projucer_artefacts/Release/以下にProjucerの実行ファイルが (Projucer.appとかProjucer.exeとかの名前で) 生成されているはずです。

Projucerを使ったコードテンプレートの生成

以下の手順でプラグインのコードテンプレートを生成します。

Projucerを開きます
Plug-in->Basicをクリック
Project Nameを入力
Path to Modulesから./lib/JUCEを選択
Create Projectをクリックして適当なフォルダにプロジェクト生成。

Save and Open in IDEをクリック

これで保存したプロジェクトのSourceディレクトリ内にPluginEditor.cpp, PluginEditor.h, PluginProcessor.cpp, PluginProcessor.hの4つのファイルが生成されているはずです。

参考: https://docs.juce.com/master/tutorial_new_projucer_project.html

プラグイン本体のCMakeプロジェクトの作成

まず生成されたSourceディレクトリ内の4つのファイルをリポジトリの./srcにコピーしてください。

次にプロジェクトルート用とsrcフォルダ以下にそれぞれCMakeLists.txtを作ります。変更内容はこちらのコミットで見れます。

公式ドキュメント: https://github.com/juce-framework/JUCE/blob/master/docs/CMake%20API.md

参考: https://qiita.com/tomoyanonymous/items/97cae1b83805ebcc2d00

以下のコマンドでプラグインがビルドできます。

$ cmake . -DCMAKE_BUILD_TYPE=Release -B cmake-build
$ cmake --build cmake-build --config Release --target JuceBenchmark_Standalone # プラグイン(スタンドアローン版)をビルド

ちなみにビルド可能なターゲットの一覧はgccやclangを使っている場合、$ cmake --build cmake-build --target helpで確認できます。

ベンチマーク対象のクラスを作成

Google Benchmarkでベンチマークをとるには測定対象をC++のクラスとして用意する必要があります。このコミットでFancyFxという名前のクラスを作りました。

ベンチマークの作成

プロジェクトルートのCMakeLists.txtにGoogle Benchmarkとその依存ライブラリのGoogle Testを追加します。

# Google Benchmark and its dependency
# https://stackoverflow.com/questions/55376111/how-to-build-and-link-google-benchmark-using-cmake-in-windows
include(FetchContent)

FetchContent_Declare(googletest
    GIT_REPOSITORY https://github.com/google/googletest.git
    GIT_TAG release-1.11.0) # 2021年12月での最新バージョン

FetchContent_Declare(googlebenchmark
    GIT_REPOSITORY https://github.com/google/benchmark.git
    GIT_TAG v1.6.0) # 2021年12月での最新バージョン

FetchContent_MakeAvailable(
    googletest
    googlebenchmark)

同じファイルの最後に以下の様に追記して、これから作る./benchmarkディレクトリをプロジェクトに追加します。

add_subdirectory(benchmark)

benchmarkディレクトリ内にCMakeLists.txtを作ります。

# JUCEのコンソールアプリとしてCMakeターゲットを追加
juce_add_console_app(JuceBenchmark_Benchmark)

# Google Benchmarkをリンク
target_link_libraries(JuceBenchmark_Benchmark PUBLIC
     benchmark)

target_compile_definitions(JuceBenchmark_Benchmark
    PUBLIC
    JUCE_WEB_BROWSER=0 # いらないものは使用しないための設定
    JUCE_USE_CURL=0)　# いらないものは使用しないための設定

target_sources(JuceBenchmark_Benchmark PRIVATE
        Main.cpp) # 測定対象のコード。次に追加します。

# JUCE関連のライブラリをリンク（必要に応じて足したり消したりしてください。）
target_link_libraries(JuceBenchmark_Benchmark PUBLIC
        juce::juce_audio_basics
        juce::juce_audio_devices
        juce::juce_audio_formats
        juce::juce_audio_plugin_client
        juce::juce_audio_processors
        juce::juce_audio_utils
        juce::juce_core
        juce::juce_data_structures
        juce::juce_dsp
        juce::juce_events
        juce::juce_graphics
        juce::juce_gui_basics
        juce::juce_gui_extra
        )

juce_generate_juce_header(JuceBenchmark_Benchmark)

Main.cppにベンチマークの中身を書きます。ここは単なる普通のGoogle Benchmarkの使い方です。

#include <JuceHeader.h>
#include <benchmark/benchmark.h>
#include <cmath>
#include "../src/FancyFx.h"

//==============================================================================
// Constants

constexpr double SAMPLE_RATE = 44100.0;
constexpr double MAX_TIME_SEC = 2.0;
constexpr double PI = 3.14159265359;
constexpr double FREQ_A = 440.0;
constexpr int NUM_SAMPLE = static_cast<int> (SAMPLE_RATE) * static_cast<int> (MAX_TIME_SEC);
constexpr int NUM_CHANNEL = 2;

//==============================================================================

// benchmark::Fixtureを継承
class FancyFxFixture : public benchmark::Fixture
{
public:
    FancyFxFixture() : buffer(NUM_CHANNEL, NUM_SAMPLE), fancy_fx() {}

    // Google Benchmarkフィクスチャ特有のセットアップ
    void SetUp (::benchmark::State& state) override
    {
        // ベンチマーク用のインプットバッファを用意。
        for (int channel = 0; channel < buffer.getNumChannels(); ++channel)
        {
            auto* channelData = buffer.getWritePointer (channel);
            for (int i = 0; i < buffer.getNumSamples(); i++)
            {
                // 440 Hz sin wave
                channelData[i] = channelData[i] * std::sin(2.0 * PI * FREQ_A * i / SAMPLE_RATE);
            }
        }
    }

    // Google Benchmarkフィクスチャ特有のテアダウン
    void TearDown (::benchmark::State& state) override
    {
    }

    // 計測対象コード。名前は任意。
    void render()
    {
        fancy_fx.render (buffer);
    }

    //==============================================================================
private:
    juce::AudioBuffer<float> buffer;
    FancyFx fancy_fx;
    
};

// Google Benchmark独自のお作法
BENCHMARK_F (FancyFxFixture, render)
(benchmark::State& state)
{
    for (auto _ : state)
    {
        render();
    }
}

BENCHMARK_MAIN();

ベンチマーク追加のコミットはこちら。

以下のようにすればベンチマークを実行できます。

$ cmake . -DCMAKE_BUILD_TYPE=Release -B cmake-build # Configureする
$ cmake --build cmake-build --config Release --target JuceBenchmark_Benchmark # ベンチマークをビルド
$ ./cmake-build/benchmark/JuceBenchmark_Benchmark_artefacts/Release/JuceBenchmark_Benchmark # 実行（拡張子はOSによって違うので適宜調節してください。）

結果の例

Run on (10 X 24.1212 MHz CPU s)
CPU Caches:
  L1 Data 64 KiB (x10)
  L1 Instruction 128 KiB (x10)
  L2 Unified 4096 KiB (x5)
Load Average: 7.95, 5.90, 4.00
----------------------------------------------------------------
Benchmark                      Time             CPU   Iterations
----------------------------------------------------------------
FancyFxFixture/render      17418 ns        17418 ns        38999

トラブルシューティング

コンパイル失敗

コンパイラ, Google Benchmark, Google Testのバージョンの組み合わせ次第で失敗することがあったのでその辺りを見直すといいかもしれません。

CPUスケーリングの警告

次のような警告が出ることがあります。

***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead.

この場合はドキュメントに従って、ベンチマーク実行前と後でそれぞれ下の様に設定すれば良い様です。

sudo cpupower frequency-set --governor performance

sudo cpupower frequency-set --governor powersave

まとめ

数字として性能がわかると安心ですね。

2021-10-24

OSSオーディオプラグイン公開のすすめ

まずここでいう「オーディオプラグイン」はこのVSTやAU、LV2などのDAW上で使えるプラグインソフトウェアのことを指しています。この文書は筆者がオーディオプラグインを公開した経験を共有して少しでも他の開発者の役に立てればなという意図の文章です。プラグインそのものについての作り方には触れておらず、どういう媒体を通して公開するのがおすすめか、などについて書いています。

以下の構成になっています。結論はまとめにあります。

BiquadLimiter（筆者の事例1）
OS-251（筆者の事例2）
プラグインを公開して良かったこと
OSSプラグイン公開のためのツール・サイト・方法の紹介
OSごとの需要の違い（おまけ）
まとめ

対象読者はOSS（または単に無料の）プラグインを作って公開したい人・またはそれに興味がある人です。また既に公開している人とっても参考になることがあるかもしれません。有料のプラグインを公開したい人も参考にできることはあるかもしれませんが、経験がないので特に言及しません。

全体的にこの文章は「自分のプラグインが刺さる人にはできるだけたくさん届いて使って欲しい」という気持ちありきで書かれています。なのでそこに興味がない人はあまり得られるものがないかもしれないので注意してください。

BiquadLimiter（筆者の事例1）

筆者は2021年10月時点で、2つのプラグインを公開しています。BiquadLimiterはそのうちの一つです。

GitHub: https://github.com/utokusa/BiquadLimiter

概要

基本的にはBiquadフィルターでLPF, HPFなどして使うものですが、内部的な計算に使われる6つのパラメータ（フィルタ係数）をユーザに公開しているものです。そのためサーキットベンディング的にフィルターで音を作れます。ただし、テキトウに設定されたフィルタ係数による出音は極めて不安定（発信して音量が発散する）なのでフィードバックパスにリミッターを差し込んで無理やり安定させてます。

公開方法

こちらの公開方法はGitHubにソースとバイナリを置くという方法です。バイナリはGitHubのReleaseという機能を使用しています。

ソースにはREADME.mdが含まれていて、ここにプラグインの説明とYouTubeデモ動画が書いているので、GitHubのリポジトリに飛ぶとどういうものか分かるようにはなっています。

世の中日本語がわかる人より英語がわかる人の方が多いので、頑張って英語で書いてます。英語はプラグインを説明してるサイトの表現を参考にしたり、Google TranslationとDeepLを行ったり来たりしながら書きました。

結果

ダウンロード数: 13 (2019-11-17から 2021-10-24まで)
DAFx2020の論文内で引用

https://dafx2020.mdw.ac.at/proceedings/papers/DAFx2020_paper_3.pdf

ダウンロード数は、（全くもって）多いという感じではないですね。論文で引用されたのがこのプラグインを公開した１番の収穫だと思います。突然論文の筆者のJatinから引用させてくれとメールがきてびっくりしたのをおぼててます。余談ですが、Jatin自身もはChowdhury DSPというプロジェクトを持っていて面白いOSS プラグインを公開しています。

OS-251（筆者の事例2）

概要

Webサイト：https://onsenaudio.com/products/os251

GitHub：https://github.com/utokusa/OS-251

JUNO-106的な使いやすさを目指した（ただしデジタルLo-fiな音をプッシュした）減算式シンセです。Onsen Audioというプロジェクトの名の下で公開しています。

公開方法

BiquadLimiterでやったことはOS-251でもやっていて、GitHubでソースとバイナリを公開していています。

ただし、今回はOnsen AudioというプロジェクトのWebサイトを用意していてその中でも公開しています。

また、外部サイトとしてはKVRというオーディオソフトウェアのコミュニティに自分のプラグインを載せています。

結果

ダウンロード数: 3 861 (ベータ版リリース時の2021-04-10から 2021-10-24まで累計)
サイト・ブログでの紹介数: 50くらい
YouTubeの動画: 5くらい

ダウンロード数は前回に比べると300倍くらいで大きな前進です。あとはブログでの紹介やYouTube動画も嬉しい変化です。個人的には思いれのあるbpbが記事を出してくれたのが嬉しかったです。

プラグインを公開して良かったこと

タイトルが「公開のすすめ」で終わってるのでこれを書かないわけには行きません。

フィードバック・感想をもらうチャンスになる

最も大事なところの一つだと思います。

筆者の場合はメールやYouTubeのコメント、友達、はたまた英語の先生から感想をもらえました。単純に良いと言われる、使ってるよと言われると嬉しいというのもありますし、要望をもらうと今後の役に立ちます。

要望に関しては結構発見がありました。個人的には最も驚いたのが、今まで最も多かった要望がファクトリープリセットを持たないOS-251に独自プリセットマネージャーを実装して欲しいというものでした。以前の考えとしては「プリセットはどうせDAW上でプラグインによらない一貫したやり方で保存・管理できるのだから、独自プリセットマネージャーは冗長だよね」と思ってましたが、実際にはそう思わない人が多いようです。どちらかというとファクトリープリセットを用意してくれという要望ならくるかなと思っていましたが、こちらの要望はまだきておらず、筆者としては予想していませんでした。

こういう知見を肌で感じながら貯めることができるので、将来プラグインを有料で作りたい人にとってもOSS/無料のプラグイン公開は有用かもしれません。

自作プラグインの安定性が（結果的に）増す

これは人にもよる気がしますが、どういうことかというと、人にプラグインを公開しようとするとある程度品質的に安定したものをリリースしたくなるでしょという話です。僕の場合、人が使うかもと思えるから、テストを書いて、CIを回して、クロスプラットフォームにできるわけです。逆にそういう開発の環境を整えていないプラグインは途中で保守がめんどくさくなって結局捨ててしいました。OS-251は信頼して使える自分好みのシンセになっているおかげで日々の音楽制作で多用しています。まあ、これは本当に人によると思うので参考まで、って感じです。

意外な良いことがあるかも

僕にとってはBiquadLimiterの論文での引用がそれでした。公開しなければ世の中にとって存在しないのと同じだが、公開すれば面白いことが起きるかもと思って公開しています。

OSS プラグイン公開のためのツール・サイト・方法の紹介

GitHub

まあこれは多くのプログラマが知ってると思いますが。大事だし、まだプログラマじゃない人もオーディオプラグイン作りたいかもしれないので。自分のコードが管理しやすくなります。OSSの場合コードはGitHubでの公開がメジャーです。逆にコードを公開せずに管理することもできます。Releaseという機能でコンパイル済みのバイナリを配布することも可能です。

公式サイト

これはそのまんまですが、ダウンロード数が増えたという意味で作って良かったんじゃないかと予想してます。残念ながら公式サイトがないBiquadLimiter→ありのOS-251で他にもたくさんのことを試したので何がどれだけダウンロード数の増加に寄与したか把握できてません。

公式サイトを持つ利点として言えそうなのは以下でしょうか。

ユーザーにちゃんと頑張っているプロジェクトだと伝わりやすい。
後述のKVRでデベロッパーのサイトを掲載するときちゃんとしたWebサイトがあった方がやや見栄えがいいです。プラグインは音楽のためのものですが（残念ながら）見栄えという視覚情報もユーザーの使用意欲のために大事です。
プラグイン情報サイトが内容を引用できる。

記事の大半が公式サイトからの引用、というスタイルのブログ・サイトはとても多いです。そして、そこからのOnsen Audioのページへのアクセスも多いです。こういうサイトに紹介してもらいたい場合、ちゃんとある程度の量の公式の情報を提供するのは記事を書く助けになると思います。情報が少なすぎると限られた時間で効率よく記事は書けないはずなので。

まあこれはKVRに同じ内容を載せれば済む話かもしれません。
Google Analyticsのようなアクセス解析ツールが使える環境ではマーケティングがしやすくなります。

筆者はそんなに有効に活用できてませんが。

公式サイトにはFirebase Hosting + Next.jsを使いました。理由は後から機能の拡張がしやすそうで、アクセス量が低い間は無料で使えるものだったからです。

もっと気軽に（かつ無料で）やりたい場合はGitHub Pagesが良さそうです。かの有名なOSSシンセのdexedも使用しています。独自ドメイン+HTTPSの使用も可能みたいなので、最初に素早く始める分にはいいオプションだと思います。

独自ドメイン

公式サイトを持つ場合のみ関係します。オーディオプラグインに限った話ではないので詳しい人は飛ばして大丈夫です。

独自ドメインというのは自分専用のドメインのことを指していて、Onsen Audioの場合はonsenaudio.comを取得しました。有料でGoogle Domainsなどから大体年間1500円くらいで契約できます。

逆に独自ドメインを使わないこともできて、その場合は裏でWebサイトを動かすサービスのサブドメインを使用することになると思います。

例えば、Firebase Hostingでonsenaudioのドメインをもらうとonsenaudio.web.appがドメインになり、GitHub Pagesだとgithub.com/onsenaudio/onsenaudio.github.ioがドメインの一例になります。

これらのサブドメインを使用するメリットは無料で使えることです。

一方独自ドメインにも優れている点はあります。

サブドメインはサブドメイン提供サービス停止で使えなくなるリスクがある一方、契約した独自ドメインが使えなくなるリスクはそれより低い。
Webサイトを移行した場合にも同じドメイン（URL）を継続して使用できる

例えば、Firebase HostingからGitHub Pagesに移行する場合、独自ドメインのonsenaudio.comは継続使用可能です。一方、Firebase Hostingのサブドメインを使用している場合、Firebase Hostingから与えられるonsenaudio.web.appはGitHub Pagesで使用できないため、サイト移行に伴ってURLを変更しないといけなくなります。

ちなみにドメインの購入にはGoole Domainsを使用しました。やや値段は高いですが、他のサイトより広告メールやトラブルが少なそうでした。

KVR

これがオーディオプラグインならではの部分だと思います。少し上の方でも触れましたが、KVRは音楽・オーディオ関連ソフトのコミュニティーサイトです。有料・無料・OSS問わず有名なプラグインの多くがこのサイトに登録しています。これが今回紹介したいことの9割方を占めていて、とても良いのでぜひ登録しましょうという話です。OS-251は多数のブログで紹介してもらえましたが、これはKVRのおかげだと思います。というのも、登録した３時間後くらいには0だったブログ記事が数件登場していたので多分正しい気がします。（速さ的に、新規のリリースを自動的に記事化してそうですね。めっちゃ頑張ってるだけかもしれませんが。）無料だからか、KVRから直接サイトに飛んできてくれる人もそれなりにいました。登録にお金も掛からねいので、特に迷わず登録すればいいと思います。

一点注意としてはデベロッパーとして登録して、承認されるまで日数を要する可能性があります。筆者の場合は半日ほどでした。

YouTube・SoundCloud

特に説明はいらない気もしますが、デモに使ってます。世の中のブログ・プラグイン情報サイトもこういうリソースがある方がプラグインを紹介しやすいんじゃないかなと想像します。

ちなみに、OS-251の場合YouTube vs SoundCloudのアクセス数の比率は3:1くらいでYouTubeの方が多いです。

Plugin Boutique

筆者のプラグインでは使用してませんが、検討の価値があるなと思います。Plugin Boutiqueは世界で最も有名なオーディオプラグイン販売サイトの一つです。有料のプラグインの購入に使用したことがある人が多いと思いますが、無料のプラグインも扱っています。

特筆すべきは、有料のプラグインは星の数ほど公開されている一方無料のプラグインは比較して少ない印象です。そしてサイトのUIは無料のプラグインがとても探しやすいです（"FREE"タブが用意されていて、カテゴリからサクサク検索できます）。そういった理由で自分のプラグインが人の目につく可能性が高いんじゃないかなと思います。

気が向いたらもうちょっと調べてみようと思います。

OSごとの需要の違い（おまけ）

BiquadLimiterはmacOSのみ対応ですが、OS-251はmacOS, Windows, Linuxに対応しています。

2021年10月24日現在で、OS-251のダウンロード数のOSごとの比率はmacOS : Windows : Linux = 2 : 4 : 1でした。

まとめ

世界中の人からのフィードバックは面白いのでぜひオーディオプラグインを公開しましょう。
OSSのオーディオプラグインを公開する時にたくさんの人の目に触れて欲しい場合KVRに登録するのがおすすめです。
YouTubeのデモ動画やある程度詳細なプラグインについての説明はプラグイン情報サイトが記事を書くのに役に立ちそうなので、公開した方がいいと思います。
使用者数に全く興味がない場合はGitHubに公開するだけでも論文に掲載してもらうなどの面白いことが起きるかもしれないのでおすすめです。

作るもの

PCB設計に使ったソフト

方針

KiCadを学ぶために見た資料

Fuzz Factoryに関する資料

ざっくりKiCad操作の流れ

基板発注

部品の購入

組み立て

ハマったところ

事前に用意するもの

空のGitHubリポジトリの用意

リポジトリにJUCEの追加（ダウンロード）

アプリ・プラグイン本体のコードテンプレートの生成

Projucerの用意

Projucerを使ったコードテンプレートの生成

プラグイン本体のCMakeプロジェクトの作成

ベンチマーク対象のクラスを作成

ベンチマークの作成

コンパイル失敗

CPUスケーリングの警告

まとめ

BiquadLimiter（筆者の事例1）

概要

公開方法

結果

OS-251（筆者の事例2）

概要

公開方法

結果

プラグインを公開して良かったこと

フィードバック・感想をもらうチャンスになる

自作プラグイン の安定性が（結果的に）増す

意外な良いことがあるかも

OSSプラグイン 公開のためのツール・サイト・方法の紹介

公式サイト

YouTube・SoundCloud

OSごとの需要の違い（おまけ）

まとめ

空のGitHub リポジトリの用意

自作プラグインの安定性が（結果的に）増す

OSS プラグイン公開のためのツール・サイト・方法の紹介