Yarns scale editor

Live here

This works with Scala files.

Oh my god……

I have been wondering about a thing for a while. What if I create a microtonal scale with say 31 tones.
How does that work with MIDI, since MIDI was not designed to handle more than 12 tones per octave…

> What if I create a microtonal scale with say 31 tones.

This can only map 12 tones - the limitations are explained here.

There’s actually a part of the MIDI standard which allows each note of the keyboard to be individually tuned (so you can “stretch” 31 tones over the 3 octaves of a keyboard) - but Yarns does not support that.

This link is now dead, 4 years old… yes… but trying to understand the limitations here. thanks!

1 Like

1. Select a .scl file or type in the text area the definition of your scale. Here is a sample .scl file for you to try!

2. Click Convert.

3. The .scl file has been analyzed, no error is reported! The interval (in cents) between each note and the root note is shown. The application tries its best to map each note in place of its nearest neighbor on the equal temperament scale – this is shown in the fuschia block.

4. Click Download .syx file to grab a SysEx file with the scale description.

5. Send the SysEx file to Yarns, using, for example, a program like SysEx Librarian or MidiOX.

6. Set Yarns’ TS (TUNING SYSTEM) setting to CU(STOM) .

7. If you want to change the root note, modify the TR (TUNING ROOT) setting. By default, the scale will start with a root of C (261.625Hz).

Yarns uses the Scale/Octave tuning 2-byte form MIDI standard. As such, the following limitations apply:

  • The same scale is repeated for all octaves – only transposed up/down by +/- 1200 cents.
  • The scale must not contain more than 12 tones.
  • The difference between a note and its equal temperament nearest neighbor must not exceed 100 cents.
1 Like

thank you, last part was what I was most curious about. Any chance in future firmware this would be changed to allow, for example, pure overtone series to be used in Yarns?

Extremely unlikely.

This caught me out - the limitations are pretty severe.

  • No control over keyboard mapping
  • no stretch tunings or any tuning that doesn’t repeat the same pitches every octave
  • no scales that deviate more than 100c from nearest E12 note or that have more than 2 notes less than 100c apart.

Before buying my Yarns I had a look at the spec and saw that it accepts scala files via the web converter thought that’s great and stupidly didn’t look into it any further. But of course there are many scala files that the converter cannot parse correctly.

The ideal solution would be to use scala files fully including the keyboard mapping files that are part of the scala standard. That would requires some thought though.

Almost as good and much easier would be to support .tun files which simply specify the pitch of all 128 midi notes in cents. Then it is just a simple lookup table to make the conversion - the Yarns doesn’t need to “understand” anything about scales or tuning.

Then the question would be how to get the .tun file into the Yarns. That’s outside my current knowledge although it shouldn’t be too hard to send sysex with a mapping for each note.

I would urge you (pichenettes) to implement something based on .tun file support since that would make the Yarns the go-to converter for microtonal music.

I am planning when I get time to set up the mutable dev environment and have a look at the code - but I have no experience with coding for external devices like this and I think it would take me too long to learn the environment even though a lookup table pitch mapping itself should be easy.

There must already be some sort of pitch mapping over the full range to allow calibration, so could this be done as another layer of that process?

There are already good products out there.


The right way of doing this would be to add support for Single Note Tuning Change SysEx; and write a tool to convert a .scl or .tun file to a SysEx dump in that format.

Then a very important feature of the module will have to be broken: the ability to save and restore the state of the module. The lookup table is too large to fit in the 1kb of storage space allocated to save each one of the 8 programs (all the settings and sequencer data already eat most of it).

That’s why I didn’t implement this feature in the first place.

1 Like

I see the problem. I’m glad that it was considered and not just overlooked.

Personally i would be happy to have only one lookup table which would be saved and restored separately from the 8 presets. I’d also be happy to have one user defined full tuning instead of a set of factory presets.

I’d also be happy to sacrifice the sequencer step memory…

But that’s just my priorities so probably doesn’t help.

I had looked at the µtune earlier today actually but it wasn’t clear to me that it supported full 128 note mapping though a more careful reading of the manual suggests it does. It could be that I will change to that.

the µtune seems like very much a work in progress - though the expander module (not yet released) seems like a great idea.

One lesser change that could be made to yarns that would improve things considerably would be to remove the “The difference between a note and its equal temperament nearest neighbor must not exceed 100 cents” restriction - though if I understand correctly that is implied in the midi protocol used to send the retuning data so would require a different sysex protocol to send the data is that right?

I’m heading towards just using a plugin on the computer as an oscillator and the yarns for gates and CCs to CVs. It breaks the modular concept but solves a lot of other issues.

1 Like

Yes, it’s from the MIDI standard.

There’s no need to stick with that method though if something else would work better.

I just realised that the µtune only has 2 CV outs and 2 gates, half the outputs of the Yarns. So it would need one expander just to equal Yarns on that.

The µtune other 4 jacks are inputs, which is way cool , but I don’t know what I would actually use them for.

Definitely going to try hybrid plugins/eurorack on this - a lot more function for less money at least until I work out exactly what I need.

You could build/buy an Ornament & Crime module. I think it can microtune your Yarn Cv’s any way you want using it’s Quantermain App, and do a lot more with the rest.

1 Like

A side point - Is there documentation somewhere of the exact pitches used in the built in scales? The names of the selected ragas? And the source of that pitch info? The manual just says they are from Maihar gharana but that doesn’t explain the derivation of the exact pitches nor give the names to match the numbers. I’d like to understand what is there.

This is probably not the kind of documentation you expect, but the Braids source code contains the full name of the scales, and the pitches (128 = 1 semitone).


Heh I had the same idea. I looked in the Yarns source code. We are talking Yarns not Braids right? BTW that braids link doesn’t work.

I found the “standard” 22 shrutis in a table and other tables selecting the shrutis for each raga.

there would be some unpicking to determine with the duplicated notes which key is filler and which key is the intended position of that note.

so now I can refine my question: how did you decide which exact shruti to use for each swara? most of the documentation I have found on different thaats and ragas just gives the scale like SrgMPdn for example specifying which semitone (for want of a better word) but not the exact shruti. ie it is unclear whether to use r1 or r2.

Do you have a source of info that specifies this?

I found the braids file you are referring to - what are the numbers in the tables representing? - they seem like cents but they exceed 1200 so they can’t be…

edit - i see that link is displaying inline now I guess you fixed it…

I fixed the link. I was talking about the Braids source code (it has the same scales as Yarns, but the code describing them easier to read).

So one octave = 1536.

1 Like

The person who sent me the charts had the exact shruti (r1, r2) given for each swara.

That’s actually the most accurate data I have ever seen, and why I used it :slight_smile: