Juce module that wraps MTS-ESP client API

Audio Plugins
1

Hi friends,

The MTS-ESP library is a super cool free library that allows a “master” plugin/app in a session to communicate microtuning and note filtering information to various “client” plugins/apps. Almost similar to Ableton Link, but for tuning. It’s a cool feature to support, but I got tired of writing #if USE_MTS_ESP everywhere within my business logic, so I decided to write a simple little Juce module that encapsulates the MTS-ESP library’s C API into an actual class, as well as provides a fallback implementation if MTS-ESP isn’t available (much simpler straightforward detuning).

This module has no dependencies aside from juce_core, and if anyone’s interested, it’s completely free and open source, go ahead and use it! :point_down:

5 Likes
2

Howdy!

I need something exactly like this, remembered your post, but the link is dead.

Did the repo go private or is it relocated somewhere?

1 Like
3

Unfortunately it’s now part of a private repo. It’s a fairly simple implementation though, basically just a class that calls through to the MTSESP API

1 Like
4

Ben might have done something much more fancier but here’s something rough I wrote right now :

Should give an approximate idea how it could be done.

2 Likes
5

No prob! Just wanted to check!

Hey nice! It pays off to be lazy weeee!

6

Hey! I’ve just written my own MIT-licensed JUCE module for this that wraps the API to make it super straightforward for people to add MTS-ESP support GitHub - jameshball/juce_mts_esp: A JUCE module wrapping the MTS-ESP client library for easy microtuning support in JUCE audio plugins · GitHub

Hopefully this is of some use to people!

Will be using this to add support to osci-render in the next version :slight_smile:

7

i absolutely agree with Ben that more plugins should support MTS-ESP and because of that it would make sense if it was integrated in JUCE directly, but we should also consider that MTS-ESP complicates certain situations dramatically.

If you just write a synthesizer where all you gotta do is convert pitch to frequency to interpret MIDI notes, you can easily implement MTS-ESP without any extra trouble in less than a day.

But for example think of plugins like Chroma or Autotune, which offer a key selector that lets the user select which pitches from an octave are used for the effect. This implies that an octave exists, which is not always the case when the whole tuning system is dynamic. Also MTS-ESP doesn’t really have a getter for the number of pitch classes per octave for the clients, so idk.. I feel like this opens up a bag of questions that need to be answered before making further decisions.

But yeah, I’m definitely working on finding solutions for this as well. MTS-ESP has the potential to enable whole new styles and genres of music and from a plugin workflow perspective, it’s also nice because it outsources the need for tuning system parameters away from individual plugins, towards the plugin that acts as the MTS-ESP master. That means that synth makers don’t have to waste space for master tune parameters anymore. They are awfully esoteric anyway.

I think we should think further than MTS-ESP though. There is more state that should be global and modulatable, just like the bpm of the project and whatever defines the tuning system. Think of swing for example. Every developer, who adds arps or sequencers to their plugins has to add various parameters just to define what the swing of the project is, and that’s just because the project can’t communicate its global swing settings to the plugins, because the plugin formats don’t ask for it. So ideally we should invent something new, that is a bit like MTS-ESP, but containing all of the information that should be global but isn’t. (and if anyone wants to improve the tuning system bit as well, pls make the noteToFreq and freqToNote functions with functional programming and not with an array, so that we can also read values that are in between integer steps)