Interview with designers: Émilie Gillet (Mutable Instruments)

*English version of the interview follows.

世界中のユーロラックメーカーの中でも、デジタルの利点を駆使したアイディアや、回路やコードをオープンにする開発スタイルの先駆けとして登場し、たちまち大人気になったMutable Instruments。代表のÉmilie Gillet氏にeメールの往復でインタビューを行いました。メーカーを始めた経緯やデザインポリシー、Mutableやユーロラックの将来についてなど、かなりディープな話題が中心になりましたが、氏の考えが良くわかるインタビューになったと思います。それではどうぞ！

Mutable Instrumentsがどのようにして始まったか教えてもらえますか?Mutableを始める前は何をしていましたか?

Mutable Instruments (M.I)を始める前、自分は信号処理(特にテンポを抽出したり、ジャンルを認識するなどの曲の自動判別)や機械学習に興味を持っていました。私はこのような技術に関連した仕事を、GoogleやLast.fm、また小さなフランスのスタートアップ企業などと行っていました。主に研究や、研究の内容をソフトウェアに落とし込むような仕事でした。

自分でエレクトロニクスや埋め込みのシステムを勉強する為、2009年にArduinoのボードで遊び始めました。私の最初の本気のエレクトロニクスのプロジェクトは、モノフォニックのハイブリッドシンセでした。いくつかのフォーラムでそのシンセについて話していると欲しがる人がいたので、DIYキットとして売り始めることにしました。このキット(Shruthi-1)はとても人気になって、何回も売り切れになった後、税金対策の為に会社を立ち上げなければなりませんでした。そしてこの会社が私の主な活動、主な収入源となっていきました。

M.Iは元々はDIYキットの形でデスクトップのシンセサイザーを売っていました。ハイブリッドモノシンセのShruthi、ハイブリッドポリシンセのAmbika、アナログモノのAnushriです。DIYの世界から離れた理由？増え続けるサポートにフラストレーションを感じたのと、もっとパワフルで美しいことをやりたかったからです。

モジュラーシンセ(特にユーロラック)にはいつ出会いましたか? 初めて知った時、すぐに自分でユーロラックメーカーをやろうと思いましたか?またその理由は?

Shruthiのオシレーターモジュールの要望をよく受けていたけれど、ユーロラックは自分にとっては奇妙でよくわからないものでした。自分がデザインしている回路を試すためにLFOやクロック、スタンダードなオシレーター波形などが必要だったので、2012年に6UのDoepferのシステムを買いました。つまりテスト用の機材として買ったのです。ですがすぐに虜になってしまい、このフォーマットでモジュールを作ると決めました。当時自分がぶつかっていた問題もこれで解決できました ー というのも、私は(Ambikaのハイエンド版のような)大きなポリシンセを当時デザインしていたのですが、リスクをとって大量生産するか迷っていたんです。自分にとっては初めての大きな投資になりそうなプロジェクトでした。ですがユーロラックモジュールは始めるにあたってより簡単に見えたし、どんどん発展し、生産コストも無理せず支払える程度だったのです。

確かあなたのプロダクツは最初から、オープンソース、オープンハードウェア(ソースコードや回路図が公開され、条件を満たせば再利用可能)でした。なぜそのようにしたのでしょうか?

シェアするのが当たり前の科学やアカデミックの世界にいたからです。ハードウェアやプラグインの会社が、彼らの商品には魔法の成分が入っているかのような宣伝をしているのに愕然としていましたし。中身を公開するのはそんなやり方への憂さを晴らしたかったのです。またハードウェアを使っている時に、内部のファームウェアやソフトウェアの制約にぶつかるのはとてもイライラするものです。ユーザーにはそういった制約を回避できるようにモジュールをカスタマイズできるようにしたかった。

あなたのオープンソース戦略は大成功しました。Parasitesのようなサードパーティのファームウェアを生み出し、ソースコードはOrnament & Crimeのような他のオープンソースモジュールに再利用されています。あなたのやり方が他のデザイナーにこれほど大きな影響を与えると思っていましたか?

いいえ。Parasitesのように深く、"公式の非公式ファームウェア"と呼べるようなものが現れるとは予想していませんでした。10や20の、個人の需要に合わせたちょっとした変更や改善を行った非公式ファームウェアが出てくるとは思っていましたが。 他のデザイナーが私のモジュールからコピーすると思っていたものと、実際に起こったことには隔たりがあります。私はもう少し対話のようなものを期待していました。私の回路図やコードを見て欠点を見つけ、より良いやり方を提案してくれる、という感じでね。

けれどOrnament & Crimeのようなものを見ることができて本当に嬉しいです。

コードを公開してもデバッグや改善にはつながりませんでしたか?コードを公開するメリットといって私がまず想像するのはその点なのですが。

私はコーディングにはとても慎重で、モジュールがリリースされる際にはバグは非常に少なくなっています。私が楽器業界の多くの開発者と違うのは、モジュールのコードの大部分をクロスプラットフォームな形で書いているという点で、その為モジュールの核となる機能のテストをコンピューターで行うことができます。ランダムな値を全てのノブやCVにアサインして数時間動かし続けても問題が起きないか確認したり、実際のハードウェアでパッチするのに何分もかかりそうな奇妙な状況等についてチェックすることができます。

ただコードを読んで理解して改善点を考えるよりも、(より大胆に)コードに何かを加えることに興味を持つ人が多かったんでしょうね。


オフィスでの仕事のやり方を教えてください。他に誰か手伝ってくれる人はいますか?

ノルマンディーのある工場とパートナーシップを結んでおり、そこが生産、テスト、パッケージにいたるまでやってくれます。皆さんが手にする完成品の箱に入れて私に送ってきます。時には人員を15人まで増やしてかかりきりになってもらうこともあります。



私自身は誰も雇わず、残り全てのことをやっています。私の1日の仕事は、ビジネスの運営(お客さんとのメールや発送作業、モジュールの修理、経営事項)と、新製品のデザインの2つに50/50で分かれています。M.Iの製品で私が行っていないのはグラフィックデザインとパネルレイアウトだけで、これは他のメーカーのデザインも手がけるHannes Pasqualiniによるものです。

シンセシスの新しい技術やアルゴリズムについてよく調査していますか?ユーロラックの世界では実現されていないようなシンセシスのフロンティアはまだあると思いますか?

新しい研究には敏感でいるようにしています。DAFXやICMCといったカンファレンスのプロシーディングに目を通したり、機械学習に関してなら何でも読みます。論文で出会ったアイディアを実装した小さいコードのコレクションをしていて、それで20個くらいモジュールが作れそうです。ですがフェアに言うと、計算パワーが足りなかったりレイテンシーがあったり、早いモジュレーションを受けられない、あるいは単にモジュラーらしくない等の理由でユーロラックには使えないけれど技術的には面白い話題もたくさんあります。そして未来的なものだけが最先端なのではなく、現在ある話題だけでも十分面白いと思います。面白いLFOの波形、音楽的に使えるランダムなデータなんていう古典的な話題の中には、今でもたくさんの発見があると思います。"フィルターモジュールにはどんなノブが必要なんだろう?"、"オシレーターではどんな波形が必要だろう?"、"エンベロープジェネレーターとシーケンサーの間には何があるだろう"みたいな疑問だって面白い発見をするには十分です。

自分で音楽を作るためのユーロラックのセットアップを持っていますか?Mutable以外のメーカーではどんなモジュールをお持ちですか?

Doepfer、Intellijel、Make Noiseの入った小さいシステムを持っていましたが、使うたびにテストしたりデバッグしてるような気分になって、モジュールを改造したくなってしまうので、個人的な使用という感じではありませんでした。去年の10月に新しい家に引っ越したのですが、その時にそこを読書や音楽鑑賞の場所にして、技術的な機材はできるだけ置かないようにしようと決めたのです。ディーター(Dieter Doepfer,Doepfer創設者)のように家にモジュラーを置かないタイプの人になりました。仕事場にはモジュール4つか5つの小さなセットアップがありますが、全て私が開発中のものです。音楽をやるためではなくテストしていじる為のものです。

INA/G.R.Mなどに見られるように、フランスには電子音楽やミュージックコンクレートの本格的な長い歴史があります。そういった歴史や研究などから影響を受けていると思いますか?

直接には受けていませんが、そういったものが常に身近にあったことは意識せざるを得ません。例えば、中学校の教科書には電子音楽についての章があって、スタジオの写真などに衝撃を受けたのを覚えています。そんなものがちゃんとした真面目な研究機関にあると知れば、キャリアのゴールにもなるでしょう。伝統的にフランスは信号処理や数学の教育にも強く、それには個人的に恩恵を受けていますし、そのおかげでGRMやIRCAMのような研究所も存在することができています。




デジタルモジュールはメニュー操作が必要だったり、一つのノブが複数の機能を持っていたり、ファームウェアの更新があったりと複雑になりすぎることがあります。こういった煩雑さに対するデザイン上のポリシーはありますか?いつかMutableから大きなOLEDスクリーンとエンコーダーでできたモジュールが出るのでしょうか。

私はそれに関していくつも間違いを犯してきました。今デザインのガイドラインを作るとすればこんな感じです。

- どんな状況でも、パネル上に書かれたラベルとノブの機能はマッチしていなければいけない。
例えば、Peaks(ノブは単純に1,2,3,4とラベルされます)やCloudsの隠し設定、Easter Egg、公式の別ファームウェアなど、無関係な機能の集合体を作ってはいけません。ただし、Ringsのモードのようなバリエーションは問題ありません。

- モジュールはミュージシャンにボタンを押させるのではなく、パッチの状態によってできるだけ自動的に設定を推測できるようにする。
Ringsのように、シグナル入力にパッチされているかどうかによって、発音のトリガーを内部か外部か切り替えるというやり方がアイディアの鍵になります。(ほとんど気付かれていないですがこれはイノベーションですよ!)

- OLEDとエンコーダーの組み合わせは、「一度設定した後は置いておく」ようなタイプ、例えばMIDIインターフェースのようなものなら使用可能。
私がER-301のようなものをデザインするとは思えません。

今私の頭に良く浮かぶのは、「パラメータの曲がり方(convexity,カーブの膨らみ)」のようなものです。良いモジュールでは、ある設定でAという結果になり、ある設定でBという結果になったら、その間にあるどんな結果も出せるようにあるべきです。またそのモジュールができることをどんどん追求していった時に、そのモジュールができないことに気づいてしまうような領域には行けないようにするべきです。このようなデザインの原則があると、例えば関係のない機能の集合体であるとか、CVであまりコントロールできないボーナス機能のついたモジュールなどが認められなくなります。

TidesとRingsが私のお気に入りのモジュールで、今の私のデザインのテンプレートになっています。私はBraidsはあまり気に入っておらず、Cloudsに至っては誤り(mistake)だったと思います。

「曲がり方」についてもう少し説明してもらえますか?私には、「AとBの間のどんな結果も出せる」というのは「曲がり方」ではなく「連続性」のような気もします。AとBをつなぐ曲線の曲がり方をきちんと調整し、その曲線状に音楽的なスイートスポット(良い音が出るポイント)ができるだけたくさんあるようにしないといけない、というような意味でしょうか?

連続性だけではありません。ユーザーに歓迎されないパラメータ領域に踏み込ませないような連続的な経路で2つの設定の間を移行できることが大事です。単純な例では、パルス幅調整をすることで1%幅から99%幅までのパルス波が出せるオシレーターなどですね。これによって1%から99%までの2つの設定の間を滑らかに移行することができます。これは連続的な経路ですが、届かない領域も残ります(もっと空洞の中を鳴っているような音など)。ノブによって連続的に移行できるだけでは問題は解決できません。

スィートスポットについてはその通りです。鍵となる概念ですね。ノブを回した時はスイートスポットを狙えるようにするべきです。

BraidsやCloudsにあるような”ランダムな機能の集合”は、あなたの嗜好と違ってユーザーには支持されているようですが、このミスマッチについては心配していますか?

そうでもありません。まずBraidsとCloudsが人気になったのは、似たものがユーロラックのマーケットになかったからです。もしCloudsがメインのグラニュラーモードだけしか持っていなかったとしてもユーザーは気に入っていくれたと思います。むしろ、使い方を学ぶのにもっと時間を割いて、もっと気に入ってくれていたかもしれません。Braidsも同じです。電源を入れてエンコーダーを触らなかったとしてもなかなかのオシレーターですよ。私は、電源を入れると1つのモードがランダムに選ばれ、次に電源を入れるまでそのモードにロックされてしまうような”Model of the day”機能をつけようか本当に考えたことがあります。

また、もしユーザーが、今の私の頭にあるような一貫性の高いモジュールよりも、以前の機能満載のモジュールの方が好きになるとしても、個人的に好きなものを作れることは嬉しいです。

2017年のMutableはまだほとんど動きがありませんが、2017年の計画について教えてもらえますか?

今のラインナップを完結させるような新しいモジュールもありますし、根本的な部分からやり直しているモジュールもあります。Mk IIのようなバージョンアップではなく、こんな感じの発想です。「今あるA,B,Cのモジュールをパッチしてできることを同じようにやれて、なおかつより曲がり方を考えた新しいモジュールX,Y,Zって何だろう?」

面白いやり方ですね。パラメータの動きの曲がり方を意識した、新しいフレームワークでは新しいモジュールは関係のないランダムな機能の集合というより、TidesやRingsのような、より首尾一貫した機能の集合体になるということですね?

その通りです。多機能なモジュールを排除するという意味ではありませんが、その場合はどの機能も根っこにある1つの原則から導かれたものか、少なくともノブやジャックの役割が一様になっていなければいけません。例えばTidesはLFO、VCO、エンベロープとして機能しますが、これはNGではありません。なぜかというと、モジュールの中身を見てみると、どのモードでも同じソースコードによって電圧の上昇と下降が行われ、上に書いた色々な機能は上昇・下降を1回だけ行うか(エンベロープ)、低速で繰り返し行うか(LFO)、高速で繰り返し行うか(VCO)だけの違いです。SergeのDSGも同じような機能性を持ったモジュールで、(電圧の上昇と下降という)根源的な要素を違うやり方で機能させています。

あなたの新しいフレームワークでデザインされたモジュールの中に、"エンベロープジェネレーターとシーケンサーの間には何があるだろう"といった問いの答えがあると期待して良いですか?

はい。ですがこれから半年の間にリリースされなかったり、結局リリースされなかったとしても怒らないでくださいね。

10年後のユーロラックの世界はどのようになっていると思いますか?ユーロラックよりも面白い機材やフレームワークが現れていると思いますか?

10年後には、現在のユーザーの半分は別のものに移行していると確信しています。けれどその分新しいユーザーが入ってくるでしょう。年を取るとノスタルジックになり、若い人だってそうなりたい人もいるはずです。

2007年のシンセの世界はどうだったでしょうか?たくさんのプラグインやデスクトップのバーチャルアナログシンセがあり、本当のアナログはあまりなく、モジュラーに至っては機密情報のような感じでした。当時から2017年までの大きな変化よりも更に大きな変化が、これからあってもおかしくありません。

より良いフレームワークがあり得るか、ですか?おそらくユーロラックよりよいモジュラーフォーマットはあるだろうし、CVコントロールを指向しないものに関してもより良いものがあるでしょう。ユーロラックと並行して大きくなってきた流れで、私が「テーブルトップオーケストラ」と呼んでいるものがあります。VolcaやPocket Operator, Meeblip,そしてギターペダル・・・これらをテーブル上でつなぎ合わせるようなスタイルです。ユーロラックと統合できるような機会もあるかもしれません。そうなるとデスクトップのユニットもモジュールも共通の規格化されたサイズや電源コネクター、ポートなどを持つことで同じケースに入ることができます。私は最初から極端に統合されてしまった道具に対しては慎重です。直接関係のない色々なものを繋いでいくと、ヨレたりグラついたり、時には信頼性まで損なわれますが、このヨレは想像力がかきたてられるし、欠陥ではありません。

 

English Version

First of all, could you explain how Mutable Instruments started? What did you do before you started your company?

Before starting Mutable Instruments, my two main interests were signal processing (especially automatic analysis of songs - to extract the tempo, recognize the genre, etc) and machine learning. I worked on these kinds of things in large tech companies: Google, Last.fm, and a rather obscure French startup. My job was mostly research, and turning research into software.

I started playing with Arduino boards in 2009 to teach myself electronics and embedded systems. My first serious electronics project was a hybrid monosynth. I talked about it on a couple of forums, and since other people wanted to build one for themselves too I started selling it as a DIY kit. This DIY kit (the Shruthi-1) became quite popular, and after having sold several batches of them I had to create a company for tax reasons, and this company gradually became my main activity and main source of income.

Mutable Instruments was originally selling desktop synths in the form of DIY kits: the Shruthi (a hybrid mono), the Ambika (a hybrid poly), and the Anrushi (an analog mono). What drove me away from the DIY world? The increasing frustration with support issues and the need to do more powerful and beautiful things...

When did you come across modular synthesizers (especially Eurorack)? Did you decide to become a Eurorack manufacturer yourself soon after this first encounter? What made you go in that direction?

People had been asking me for a Shruthi oscillator module for a while but Eurorack was really something strange and foreign to me. In 2012 I bought a 6U Doepfer system, primarily because I needed LFOs, clocks, raw waveforms etc to test the circuits I was designing, like the Shruthi filter boards. I really thought of it as a purchase of test equipment! But I instantly got hooked and decided to make modules in this format. It solved nicely a problem I was facing at the time; I had designed a big polysynth (a higher-end version of the Ambika) and I was hesitant as to whether I should take the risk to launch it via mass-production. The money I had to invest was very big, and this was my first serious industrialized project. The Eurorack modules looked like an easier way to get started, with a more progressive curve and production costs I could afford.

If I remember correctly, your products have been open-source and open-hardware from the start. Why did you make that decision? (related question follows)

It's part of my scientific/academic background in which sharing is a habit. It's because I'm really appalled by the way some hardware or plug-in companies make people believe there's a "magic ingredient" in their product: being transparent about how your product works is a remedy against that. It's also because I know how frustrating it can be when we hit firmware or software limitations when using a hardware product - I wanted to give my customers the ability to customize their modules so they could bypass these limitations.

It seems your open source strategy has been a great success, because many third-party alternative firmwares have emerged like Parasites, and your codes are recycled in other open-source modules like Ornament & Crime. Did you imagine your strategy would have such great influence on other designers?

I did not really anticipate what happened. I did not expect something like Parasites, which is very deep, becoming the "official unofficial firmware". I thought there would be ten or twenty alternative firmwares, with minor changes or improvements suiting personal needs.

There's a bit of a mismatch between the things I expected other designers to "copy" from my modules, and what has actually happened. Somehow I expected more of a dialogue - people looking at my schematics or code and finding flaws, giving me suggestions about things I could do better. But I'm really glad to see something like the Ornament & Crime.

So making your code public did not help you debug/improve your code? That's what I would have expected to be the chief merit of making the code public in the first place!

I’m very meticulous with coding and there have been very few occurrences of bugs getting into the modules once they are released. One thing that sets me apart from other developers in the world of music gear is that a large section of each module’s code is written in a cross-platform way - which means that I can test and run the core functionality of the module on my development computer, not on the actual hardware. This allows me to conduct “monkey tests” in which I feed random values to all knobs/CVs for hours and check that nothing crashes, and more generally to check what would happen in strange situations that would take minutes to reproduce with the actual hardware.

Overall I think there are more people interested in adding to the code than just reading it and trying to figure out how it works and how it could be improved.

Could you explain how you run your business at Mutable HQ? Do other people help you there?

I have a partnership with a contract manufacturer in Normandy who handles all the manufacturing, testing, packaging - they ship me palettes of finished boxes, the same boxes you buy. At times there are up to 15 people working simultaneously on the modules in their factory. As a result, I don't have any employees and do everything else by myself. My day is split 50/50 between running the business (answering customers' questions, shipping orders, repairing modules, administrative duties), and designing new products. The only thing in a Mutable Instruments product that I do not create myself is the graphic design and panel layout - this is handled by Hannes Pasqualini, who now designs for other brands too.

Do you often research new techniques/algorithms for synthesis? Do you think there are still many new frontiers in the field of synthesis that have not implemented yet in the world of Eurorack?

I try to stay up-to-date with the latest research, reading the proceedings of conferences like DAFX or ICMC plus whatever is going on in machine learning. I have a collection of small code snippets implementing ideas I encounter in papers, enough to make 20 modules or so. But to be fair, there are a lot of exciting things that are not ready for Eurorack, either due to issues of computational power or latency, or because they would be deemed too "unmodular" or would not handle fast modulations. And the future is not the only frontier, we can also look at the present. I think there are still many things to be discovered on boring, old-fashioned, small things like generating families of interesting LFO waveforms or musically useful random data. Just questioning things like "What knobs should there be on a filter module?", "Which waveforms should be available in an oscillator?", "What's in the space between an envelope generator and a sequencer?" is enough to enable interesting discoveries.

Do you have your own Eurorack set-up for music creation? If so, what other manufacturers/modules do you have in it?

I had a small system with Doepfer, Intellijel and MakeNoise modules; not my own modules because every time I used them it felt like doing testing/debugging, and this gave me urges to tweak them. Last October I moved to a new apartment and decided that it would be a space for reading and listening to music, with as little as possible technical equipment, cables, clutter... so I did not bring any music/audio equipment in. I guess I'm like Dieter Doepfer now, with no modular at home. At work I have a small setup with 4 or 5 modules - everything new I'm developing; but it's more testing and playing around than a true musical project.

France has been famous for having long history of electronic music/musique concrète like INA/G.R.M. Are you influenced at all from that kind of history/research?

Not directly, but I can't help thinking that this stuff has been around all the time - for example there was a chapter about it in my junior high school music textbook and I remember being impressed by the studio photos. Just knowing that this thing exists, that it's happening in a legitimate and serious institution is enough to turn it into a career goal. There's also a good tradition of teaching signal processing and mathematics in France that I benefited from, and that accounts for the existence of institutes like the GRM or IRCAM.

Sometimes digital modules get too complex because of menu-diving, multi-functions per knob, many firmware updates, and so on. Do you have any specific design policy on module complexity? Will we see modules from you in the future that have big OLED screens and encoders?

Well, I made lots of mistakes on that front! My current set of guidelines would be:

- Under any circumstance, the label printed on the panel should match the knob's function.
This prohibits modules that are collections of unrelated functions like Peaks (with knobs labelled simply 1, 2, 3, 4), hidden settings like Clouds, or easter eggs, and releasing "official" alternative firmwares. Variations (like Rings' various modes) are OK.

- The module should try to infer as many settings as possible from the way the module is patched, instead of asking the musician to press buttons.
The way Rings switches to an internal/external exciter depending on whether the signal input is patched is a key idea (an innovation few noticed!).

- OLED displays and encoders might be OK for something requiring many "set and forget" settings, like a MIDI interface.
But I don't see myself designing something like the Orthogonal Devices ER-301.

The notion that stays a lot in my head at the moment is that of "convexity". A good module should feel "convex" in the sense that if you can get result A from it and another result B from it, you should also be able to get anything inbetween. Or the things it can do should not push you towards a direction where you'll notice the things it cannot do. As a design principle, that rules out a lot of things, like collections of unrelated functions, or modules with "bonus" features that are not fully CV-controllable.

Tides and Rings are my favorite modules, and they are serving as templates for new designs at the moment. Braids is not my favourite module, and I consider Clouds a mistake.

Could you elaborate more on "convexity"? "Getting any result between A and B" sounds like continuity, not convexity. Do you mean that you need to fine-tune the convexity of the continuous virtual curve linking A and B, to make the curve have as many sweet spots as possible?

It’s not just continuity (or path-connectedness: that would be the more accurate notion) - you can have a continuous path between two settings that still does not get you where you want it to go. A silly example would be a VCO whose PW control behaves this way: turn it CCW and you get a pulse with a 1% ratio, turn it CW and you get a pulse with a 99% ratio, and inbetween you just get a crossfade between these two settings. That’s a continuous path, but it still leaves a gap, there’s a type of sound (the “hollow” square with a 50% duty cycle) that this would not cover. So having all continuous settings (all knobs, no switch) doesn’t solve the problem.

But you’re right about the sweet spots - that’s the key notion… Make sure that when turning a knob, we visit the sweet spots.

People seem to love the "collection of random features" found on Braids and Clouds, as opposed to your like/dislike. Do you worry about this mismatch?

Not much. First, because what made Braids and Clouds popular was that there was nothing like them before on the Eurorack market. If Clouds only had its main granular mode I’m pretty sure that people would have still loved it - and maybe they would have taken even more time to learn how to use it and loved it more. Same for Braids - even if you power it on with one model and don’t touch the encoder (I really thought about this “model of the day feature” - the module powers on in one randomly chosen model and stays locked there until you power it on again), it’s a fine oscillator.

And well, even if people prefer the “old”, feature-loaded module instead of the more streamlined things that now occupy my mind - at least I will have the happiness of making things I’m more happy with.

Mutable Instruments in 2017 has been pretty quiet so far. What are your plans for 2017?

New modules completing the existing collection, but also reworking the fundamentals - not in the sense of MkII versions, but through this kind of approach: "Can we do what modules A, B, C do when they are patched together with new modules X, Y, Z - with X, Y, Z being more 'convex' than A, B, C?"

That type of reworking sounds interesting. So the new modules (serving in a more convex framework) won't have unrelated random functions, but will have more coherent collections of functions like in Rings and Tides?

Yes. This doesn’t mean I will exclude multi-function modules, but if they are multi-function, it should be either from a same underlying principle, or at least with uniformity about what their knobs/jacks do. For example, even if Tides can work as an LFO, VCO, envelope generator, I don’t see it as an “evil” multi-function module, because if you look inside the code of the module, you see the same code managing a voltage going up and down - and the various functions are just obtained by changing if this up/down movement is done once (envelope), or many times at low frequencies (LFO), or many times at high frequencies (VCO). The Serge DSG is of this same kind of multi-functionality flavour - where there’s one underlying principle that can be used and abused in different ways.

Can we expect modules in your new framework that will answer questions like, "What's in the space between an envelope generator and a sequencer" (ref answer to Q6, above)?

Yes, but don’t nag me about it if it’s not released in the next six months, or is not released at all.

What will the world of Eurorack look like in ten years' time? Do you think there will be a more interesting tool/framework than Eurorack at that point?

I'm pretty sure half of the people will have moved on to something else, but they'll be replaced by new people: old people getting nostalgic, young people wanting to get retro, etc.

How was the world of synths in 2007? Lots of plug-ins and desktop VAs, not much analog stuff, and modular was confidential. There's no reason 2027 will be less different from 2017 than 2017 is from 2007.

Could there be a better framework? Maybe a modular format better than Eurorack, and not geared towards CV control. One trend that has grown in parallel with Eurorack is what I call "tabletop orchestras" - boxes like Volcas, Pocket Operators, Meeblips, guitar pedals... all patched together on the table. Maybe there would be an opportunity for merging this with Eurorack so that desktop units and modules could all have standardized sizes, power connectors, I/O ports and live happily together in the same case. I would be wary of some extremely integrated tool - there's a kind of "wonky" feel to connecting unrelated things together in a not-always-reliable way. This wonkiness is inspiring, and is not a defect that should be fixed.