ADC Japan 2026

Building a great-sounding audio plugin is no longer enough to ensure real-world adoption. In today’s highly saturated plugin market, distribution has become the missing layer between development and sustainability. Many technically strong plugins remain invisible simply because developers do not have a clear distribution strategy. How do musicians actually discover plugins today? Which channels are worth investing time and energy into, and which ones look promising but rarely lead to real adoption?

In this talk, I will approach distribution not as marketing, but as a product design and infrastructure problem. I will share real-world experience from running my a boutique audio plugin company and walk through the decisions behind building visibility, discoverability, and long-term viability. I will show how distribution choices influence product design, onboarding, and communication, and why these decisions should not be treated as post-launch tasks. The session focuses on practical examples, measurable outcomes, and clear prioritization rather than hype or short-term tactics. By the end of the talk, attendees will have a clearer mental model of how distribution fits into the audio plugin lifecycle, and how to approach it in a focused and sustainable way without losing sight of development.

Topics covered
- Distribution vs marketing and why the distinction matters for developers
- How musicians discover and evaluate audio plugins today
- Direct sales, platforms, resellers, creators, and affiliate ecosystems
- Distribution as a product constraint, designing plugins that are easier to explain, demo, and adopt
- Email, content, and partnerships as part of onboarding, not post-launch add-ons
Common distribution mistakes indie developers make and how to avoid them

素晴らしいサウンドのオーディオプラグインを開発することだけでは、実際の採用を保証するには十分ではなくなりました。今日の飽和状態にあるプラグイン市場では、ディストリビューションが開発と持続可能性の間の欠落したレイヤーになっています。技術的に優れた多くのプラグインは、開発者が明確なディストリビューション戦略を持っていないという理由だけで見えないままになっています。ミュージシャンは実際に今日どのようにプラグインを発見するのでしょうか？どのチャネルに時間とエネルギーを投資する価値があり、どのチャネルは有望に見えますが実際の採用につながることはめったにないのでしょうか？

このセッションでは、ディストリビューションをマーケティングではなく、プロダクトデザインとインフラストラクチャの問題として扱います。私のブティック型オーディオプラグイン企業の運営から得た実世界の経験を共有し、可視性、発見可能性、長期的な実行可能性を構築するための決定について説明します。ディストリビューション選択がプロダクトデザイン、オンボーディング、コミュニケーションにどのような影響を与えるのか、そしてなぜこれらの決定をローンチ後のタスクとして扱うべきではないのかを示します。このセッションは、実践的な例、測定可能な成果、明確な優先順位付けに焦点を当てており、ハイプや短期的な戦術ではありません。このセッションの終わりに、参加者はディストリビューションがオーディオプラグインのライフサイクルにどのように適合するかについて、より明確なメンタルモデルを持つようになり、開発を見失うことなく焦点を絞った持続可能な方法でそれにアプローチする方法を理解するでしょう。

カバーするトピック
- ディストリビューションとマーケティングの違い、および開発者にとってなぜその区別が重要なのか
- 今日ミュージシャンがオーディオプラグインをどのように発見および評価するか
- 直販、プラットフォーム、リセラー、クリエイター、アフィリエイトエコシステム
- プロダクト制約としてのディストリビューション、説明、デモンストレーション、採用がしやすいプラグインの設計
- メール、コンテンツ、パートナーシップをローンチ後のアドオンではなく、オンボーディングの一部として
インディー開発者が犯す一般的なディストリビューション上の誤りと、それを回避する方法

Recent advances in AI music technology have largely focused on generating and manipulating raw audio. Diffusion models, neural synthesizers, and source separation systems have made waveform-level processing more powerful than ever. However, many creative tools for musicians still struggle with control, editability, and real-time interaction when operating directly on audio.

In this talk, we explore why symbolic representations—especially MIDI—remain a crucial layer for building practical and expressive AI music tools.

Rather than treating MIDI as a legacy protocol, we examine how it provides a powerful abstraction for structure, intent, and musical interaction. MIDI enables precise editing, controllable generation, and seamless integration with existing creative workflows. When combined with modern AI models, it becomes a flexible interface between human musical ideas and machine-generated content.

Through examples from our own researched, developed and deployed tools, we show how MIDI can serve as the control plane for generative music tools. Topics will be on the lines of symbolic-to-audio pipelines, AI-assisted composition workflows, expressive performance data, and hybrid systems that combine MIDI reasoning with neural audio synthesis.

The talk argues that many future music tools will not be purely “audio AI,” but instead layered systems where symbolic representations guide audio generation.

AI音楽技術の最近の進展は、主に生オーディオの生成と操作に焦点を当ててきました。拡散モデル、ニューラルシンセサイザー、ソース分離システムは、波形レベルの処理をこれまで以上に強力にしました。しかし、ミュージシャン向けの多くのクリエイティブツールは、オーディオを直接操作する際に、制御性、編集可能性、リアルタイム相互作用の面で依然として課題があります。

本トークでは、シンボリック表現、特にMIDIが、実用的で表現力豊かなAI音楽ツールを構築するための重要なレイヤーとして残る理由を探ります。

MIDIをレガシープロトコルとして扱うのではなく、構造、意図、音楽的相互作用に対する強力な抽象化を提供する方法を検討します。MIDIは正確な編集、制御可能な生成、既存のクリエイティブワークフローとのシームレスな統合を可能にします。最新のAIモデルと組み合わせると、人間の音楽的アイデアと機械生成コンテンツの間の柔軟なインターフェースになります。

当社が研究、開発、導入したツールの例を通じて、MIDIが生成音楽ツールのコントロールプレーンとしてどのように機能できるかを示します。トピックは、シンボリック・トゥ・オーディオパイプライン、AIアシスト作曲ワークフロー、表現力豊かなパフォーマンスデータ、およびMIDI推論とニューラルオーディオ合成を組み合わせたハイブリッドシステムについてです。

このトークは、今後の多くの音楽ツールは純粋な「オーディオAI」ではなく、シンボリック表現がオーディオ生成を導くレイヤー化されたシステムになるだろうと主張しています。

Most audio plugins need parameters. For example, a low-pass filter plugin can provide a cutoff frequency, a slope steepness, and a resonance parameter.

All audio plugin formats provide some mechanism for defining and interacting with plugin parameters. The JUCE C++ framework, the most popular cross-platform framework for developing audio plugins, provides an abstraction layer over those parameter mechanisms.

Yet defining, using, and maintaining parameters is a non-trivial task. There are various features a plugin developer may need, like,
* type safety,
* range and value validation,
* value formatting and labeling,
* observing (for UI controls or audio processing updates),
* smoothing,
* serialization (e.g., for presets),
* parameter groups, or
* meta parameters.

Over the years, a few parameter management systems for JUCE-based plugins have been proposed, but none have been without serious flaws. The most famous of them, `AudioProcessorValueTreeState`, has been widely criticized.

This talk will provide a tour of current plugin parameter challenges and existing solutions, and then propose a new solution based on the **type erasure technique**: an advanced C++ design pattern meant to replace polymorphism in a non-intrusive manner.

Type-erased audio parameters
* guarantee type safety (no low-level representation, no `dynamic_cast`s)
* provide the necessary abstractions to use heterogeneous parameter instances as a collection
* don't use virtual polymorphism (no base classes or interfaces)
* enable easy feature addition without forking JUCE or writing a new parameter class system from scratch (you don't pay for what you don't use)
* is relatively easy to integrate into existing codebases.

The talk is aimed at intermediate or advanced C++ developers who are familiar with at least one parameter API, such as the one in JUCE.

ほとんどのオーディオプラグインにはパラメータが必要です。例えば、ローパスフィルタープラグインは、カットオフ周波数、スロープの急峻さ、およびレゾナンスパラメータを提供できます。

すべてのオーディオプラグイン形式は、プラグインパラメータを定義および操作するためのメカニズムを提供しています。オーディオプラグイン開発用の最も人気のあるクロスプラットフォームフレームワークであるJUCE C++フレームワークは、これらのパラメータメカニズムに対して抽象化レイヤーを提供しています。

しかし、パラメータの定義、使用、および保守は簡単ではありません。プラグイン開発者が必要とする可能性のあるさまざまな機能があります。例えば:
* 型安全性
* 範囲と値の検証
* 値のフォーマットおよびラベリング
* 監視（UI制御またはオーディオ処理の更新用）
* スムージング
* シリアライゼーション（例：プリセット用）
* パラメータグループ
* メタパラメータ

長年にわたり、JUCEベースのプラグイン向けのパラメータ管理システムがいくつか提案されてきましたが、いずれも深刻な欠陥がありません。それらの中で最も有名な`AudioProcessorValueTreeState`は、広く批判されています。

このトークでは、現在のプラグインパラメータの課題と既存のソリューションについて説明し、その後、**型消去技術**に基づく新しいソリューションを提案します。これは、ポリモーフィズムを非侵襲的な方法で置き換えることを目的とした高度なC++デザインパターンです。

型消去されたオーディオパラメータ:
* 型安全性を保証します（低レベルの表現がない、`dynamic_cast`がない）
* 異種のパラメータインスタンスをコレクションとして使用するために必要な抽象化を提供します
* 仮想ポリモーフィズムを使用しません（ベースクラスやインターフェースがない）
* JUCEをフォークしたり、パラメータクラスシステムを一から作成したりすることなく、簡単に機能を追加できます（使用しないものに対しては料金を払いません）
* 既存のコードベースへの統合は比較的簡単です。

このトークは、JUCEのようなパラメータAPIに少なくとも1つ精通している中級以上のC++開発者を対象としています。

What happens when you give an LLM the ability to not just control a synth's parameters, but understand its signal flow and hear the results? In this talk, I'll explore that question live on stage — starting with a basic synth sound, describing what I want in plain language, and iteratively shaping it into a fully designed lead patch. Along the way, we'll see where an LLM can genuinely reason about sound design versus where it falls short, and what kind of information — from signal flow metadata to real-time spectral analysis — makes the difference between an AI that blindly turns knobs and one that can diagnose and fix a problem.

LLMにシンセのパラメータを操作させるだけでなく、シグナルフローを理解させ、その結果を「聴かせる」ことができたら、何が起きるでしょうか。このトークでは、その問いをステージ上でライブで探ります。基本的なシンセサウンドから始めて、自然な言葉でイメージを伝えながら、完成されたリードパッチへと段階的に作り上げていきます。その過程で、LLMがサウンドデザインについて本当に推論できる部分と、まだ力が及ばない部分を明らかにし、シグナルフローのメタデータやリアルタイムのスペクトル分析といった情報が、ただノブを回すだけのAIと、問題を診断して的確に修正できるAIとの違いをどう生み出すのかを見ていきます。

Music technology has enabled artists and engineers to create highly interactive musical systems in many different forms of media, from games, to art installations and instruments. In this talk I share ideas on ways to approach technology and tools such as data, sensors and hardware, MIDI or OSC, and programming languages, in order to create systems that are intuitive to engage by the audience across media that involves sound.

音楽技術により、アーティストとエンジニアは、ゲーム、アート・インスタレーション、楽器など、多くの異なるメディア形式で、高度にインタラクティブな音楽システムを作成することができるようになりました。このトークでは、データ、センサー、ハードウェア、MIDIやOSC、プログラミング言語などのテクノロジーとツールに取り組む方法についてのアイデアを共有し、音を含むメディア全体で観客が直感的に操作できるシステムを作成する方法をお話しします。

Despite Rust's benefits, it has seen limited adoption due to factors including existing ecosystems built for other languages (JUCE, VST3 SDK), less overall time to grow, and the general appeal of familiarity.

This talk showcases CSick, a scaffolding system for automated FFI generation designed to provide a bridge, not a ferry, between C++ and Rust.

Previous solutions have focused on addressing developers' reluctance by easing the transition with familiar workflows adapted for Rust development (e.g. cxx-juce), with Rust as the forerunner and C++ only when necessary.

By contrast, CSick is built to allow gradual adoption—integrating Rust code into existing C++ codebases one chunk at a time—allowing developers to reap Rust’s benefits without entirely jumping ship.

Rustの利点にもかかわらず、他の言語向けに構築された既存のエコシステム（JUCE、VST3 SDK）、成長に費やされた全体的な時間の不足、および親しみやすさへの一般的な訴求力といった要因により、採用は限定的です。

このトークではCSickを紹介します。これはC++とRust間のブリッジ（フェリーではなく）を提供するために設計された、自動FFI生成用のスキャフォールディングシステムです。

以前のソリューションは、Rust開発に適応した親しみやすいワークフローで移行を容易にすることで、開発者の抵抗感に対処することに焦点を当ててきました（例：cxx-juce）。Rustが主導的な役割を担い、C++は必要な場合のみです。

これとは対照的に、CSickは段階的な採用を可能にするために構築されています。既存のC++コードベースにRustコードを一度に1つのチャンクずつ統合し、開発者が完全に乗り換えることなくRustの利点を享受できるようにします。

Our company develops a singing voice synthesis application for PC, and based on that architecture, we undertook implementation as an AUv3 plugin for iOS. However, requirements specific to singing voice synthesis—such as UI design premised on lyrics input, handling of large-scale models, and high initialization costs—are closely related to AUv3's execution model, sandbox constraints, extension launch restrictions, and iOS memory management characteristics.

In this presentation, we will organize the technical constraints we encountered in the process of realizing a singing voice synthesis application as an AUv3 plugin, and share perspectives that should be prerequisites when designing AUv3 in a mobile environment.

弊社ではPC向け歌声合成アプリケーションを開発しており、そのアーキテクチャを基にiOS向けAUv3プラグインとしての実装に取り組みました。しかし、歌詞入力を前提とするUI設計、大容量モデルの扱い、初期化コストの高さといった歌声合成特有の要件は、AUv3の実行モデルやSandbox制約、Extension起動時の制限、iOSのメモリ管理特性と密接に関係します。
本講演では、歌声合成アプリケーションをAUv3として成立させる過程で直面した技術的制約を整理し、モバイル環境でAUv3を設計する際に前提とすべき観点を共有します。

In composition and arrangement using existing DAWs, users set appropriate timbres for each track from vast timbral datasets classified by category (such as instruments and sound source names). We reconsider this current text-based timbral search interaction itself and propose a new approach to expand creativity across diverse timbres. We have removed the conventional concept of timbral categories and have: 1) calculated relationships between timbres depending only on acoustic features, and 2) constructed an interface that enables visual confirmation of relationships between timbres. By visualizing similarity between timbres across categories, we provide serendipitous timbral exploration not constrained by conventional timbral categories. In this presentation, we will discuss the background of the proposed approach, technical overview, and usefulness based on user testing.

既存のDAWを用いた作曲や編曲では，カテゴリ（楽器や音源名など）ごとに分類された膨大な音色データセットの中からユーザが適切であると考える音色を各トラックに設定しています．我々は，このようなテキストベースで音色を検索する現状のインタラクション自体を見直し，多様な音色に創造性を広げるための新たなアプローチを提案します．従来の音色カテゴリの概念を取り払い，１）音響特徴量のみに依存した音色間の関連性を計算し，２）視覚的に音色間の関係を確認可能にするインタフェースを構築しました．カテゴリを横断して音色間の類似性を可視化することで，従来の音色カテゴリに縛られない偶察的な音色探索を提供します．本講演では，提案アプローチの背景，技術概要，およびユーザテストによる有用性について口述します．

mimium (https://mimium.org) is a functional programming language designed for audio processing with syntax similar to Rust. It runs on both native and web platforms, and allows oscillators and signal processing to be defined from a very low level. It also features a proprietary live coding capability based on differential analysis of source code, enabling hot-swapping of signal processing code without resetting the internal state of the audio. This presentation will explain the details of its design and implementation.

mimium(https://mimium.org)は、Rustに似たシンタックスを持つ関数型のオーディオ処理を目的としたプログラミング言語である。ネイティブ/Webのどちらでも動作し、オシレーターや信号処理を非常に低レベルから定義することができる。また、ソースコードの差分解析に基づく独自のライブコーディング機能を持ち、オーディオの内部状態をリセットせずに信号処理のコードをホットスワップすることができる。本講演ではその設計と実装の詳細を解説する。