MTS-ESP support

[tank-trax]

very nice instrument.... have you thought of adding KBM, or possibly adding MTS-ESP support?

[baconpaul]

If you want to add kbm support, https://github.com/surge-synthesizer/tuning-library is a header only library which has full KBM support including a bunch of gnarly edge cases (like tuning center is an unmapped note, non-monotonic cases, and kbms which extend the scale).

If you want to add MTS support, the current night of SurgeXT can serve as an MTS-ESP source if you don't have their software.

If you want to do neither, then neither of those things will help :)

[Andreya-Autumn]

Hello! I just tried out this instrument, and can only agree with the above. Interesting sounds in here, very nice work!

I'm a big fan of MTS-ESP personally, for its ability to make all loaded instruments adhere to the same tuning, and the ability to let that tuning change dynamically over time. Seems like it may be a perfect addition to the xenharmonic quantization you have already. https://github.com/ODDSound/MTS-ESP if you're interested.

Looking forward to exploring this synth more! :)

[Xenakios]

Just to further explain the reasons for having KBM and MTS-ESP support :

It is not enough to have support for loading just Scala files to get consistent results across multiple synths from multiple manufacturers. Scala files by themselves don't contain the information needed to do the actual frequency mapping for the synth. This can lead to inconsistencies like different synths playing completely different frequencies when the user presses, say, the key 60/Middle C on their keyboard. KBM and MTS-ESP have been designed to solve this problem. KBM support is a more manual workflow for the user, as every relevant synth instance in their composition session would need to have the same Scala and KBM files loaded. MTS-ESP is a solution where the tuning data is provided from a common shared source and can be changed on the fly, affecting all the connected instruments.

These kinds of mappings also allow to do things like use more sparse pitch sets from a larger overall tuning, without having to edit original Scala file. One could start for example from the octave divided by 31 and then use the Xenakis sieve theory to select fewer pitches out of those to be used via MIDI key messages.

[raphaelradna]

Hi all—thanks for your interest in Xenos and for the conversation above. I'm aware of kbm (keyboard mapping) files and the ways in which they are distinct from and complement scl files. They are not implemented here because Xenos doesn't use scl to remap MIDI note input but rather as a way of loading scales into its quantizer. Xenos converts scale degrees from the scl to frequencies based on the absolute pitch of each voice, its pitch range, and the "root" parameter, conveniently circumventing the problems mentioned by @Xenakios since no keyboard mapping is necessary or done. While this approach is a bit different from other microtonal synths and has some drawbacks, imo it keeps things simple and within the stochastic spirit.

[tank-trax]

perhaps a way to set a frequency for a root note, like to be able to set A4 to 440 or C4 to 261.626Hz?

[raphaelradna]

Sure—I think I'd roll something like that into a fuller tuning implementation down the line, using one of the options above. A workaround for now is to use the pitch bend.

[Xenakios]

I now finally worked on replacing the tuning/quantization for a few hours and got something going. My implementation uses the above mentioned Surge Synth Team tuning library so there is support for both Scala and KBM files. Additional work is of course still needed, so I am not yet going to make a pull request. MTS-ESP seems like a possible addition too, but it's perhaps not the best fit into Xenos because of the stochastic pitch modulation that could require an extended pitch range for the quantization. (The Surge Tuning Library generates 512 possible pitches, while MTS-ESP is limited to 128 pitches.)