Proposal for third-party devs: Poly External Scale format [Revision 2]


My module collection strongly focuses on using scales and chords, and I find it useful to share a scale across devices using a poly cable. I’m using a very intuitive format, barely worth specifying, but should anyone want to interoperate with it (and I hope people will), I think it’d be convenient for users if we gave it a more generic name than “Compatible with Aria’s modules”.

Like portable sequences, it’s just meant to propose an optional thing third-party developers can elect to implement or ignore.

Here’s my proposal:

In my modules, I frequently make use of the ability to quantize to a scale or chord, using a polyphonic cable to transfer external scales between devices.

I am calling it the Poly External Scale format. This format is drafted primarily considering the uses I personally have in mind for it, and the ways I expect to extend it.

I encourage other developers to use it, if it makes sense for their module. And if it doesn’t make sense, I’m requesting you use a different term than “Poly External Scale”.

  • The format is concerned with sharing data about the 12 semitones of an octave. It is not concerned with which octave it is.
  • A Poly External Scale has 12 channels, one per semitone of the octave. The first channel is C, the second C#, and so on. Twelve-tone equal temperament is assumed.
  • The valid range of voltage for each channel is 0V~10V.
  • You are not guaranteed specific voltages: your module should accept any valid input and do something sensible with it.
  • When a channel recives less than 0.1V, it is considered to receive 0V.
  • Modules sending a scale should use 0V for a disabled semitone, 8V for an enabled semitone, and optionally, 10V for the tonic if it is known.
  • Modules sending probabilities should use the full range: 0.1V for 1%, 10V for 100%.
  • Modules that accept a scale to determine which notes are enabled or disabled should accept any input above 0.1V as enabled, and pick the channel with the highest value as the tonic if this information is used.
  • Jacks that support the format should be named something such as “Ext.”, “Ext. scale”, “Poly External Scale”, etc.
  • In the documentation, name it “Poly External Scale” consistently, and mention it’s compatible with modules by other developers.

This format is very self-evident, so I can’t claim any degree of ownership over it. I just think it would be useful for users to have a consistent naming scheme for it, so I’m proposing one. When users see “Poly External Scale”, they know it’s probably compatible.

A scale is just 12 bits of data: for sending data in between quantizers, it would have been a higher performance solution to send it encoded as voltage. However, such a format would not be intuitively hackable by the user, and that’s what matters to me. You can understand Poly External Scales simply by observing and altering their values, you don’t have to read this document or do maths to understand them.

Let me know what you think. If there’s a general consensus, I’ll add a file with that mini-specification to my documentation site, and alter my documentation to use this term consistently.

Edit 1: Clarified design goals, per conversation with @unlessgames

Edit 2: Revision 2 carries arbitrary information about the tonic or probabilities


I like it! The only missing thing I see is that there is no information about where the scale starts (this could come handy when using the format in something other than a regular voltage quantizer). An optional “field” on the remaining 4 channels would solve this but might make the format more complex than you want it to be, it would also get lost when using less than 13 channels (although the less-than-12-channels cases don’t seem too useful even if they are supported).

An alternative would be to use integer volts showing note numbers (since we can have up to 12 volts on a cable, so the 0-11 range would cover the twelve tone scale). This could have some advantages over using gates. For example custom starting note/order, using only as many channels as long the scale is and optional detuning of the notes.

My thinking is that there are many ways to split an octave, but xenharmonic music is a niche, even among modular users. And there is already a way to communicate chords across devices: simply send V/Oct polyphonically. This format is only concerned with representing a scale in the sense of “the semitones in 12TET that are currently allowable, on any octave”.

When a user sees the following, I think they don’t need a manual or a specification to immediately understand how they can play with the format:

Extending the format to cover more use cases would go against being easy to hack.

This explains your viewpoint clearly, thanks. It is just that when I hear “scale” I always think about not only the notes but a start or tonic, which quantizers usually ignore. If I were to create a sequencer for example that has an external scale input, I’d want it to know where the scale starts but of course there could be a separate cable that carries this info.

1V/NOTE would be maybe a bit more intuitive on a scope than 1V/OCT. Similarly to PES, it is also unrelated to octaves and faster to process than v/oct. It might be just as hackable as gates though (just in different ways), but I agree that twelve gates are even more intuitive.

Xenharmonic music might be niche, but tools that make it more easy to experiment with it could help on that front, it would be completely optional though (most modules could just floor the value to ignore microtuning altogether).

I need to also clarify: this format is already implemented in 3 released module families. A 4th in development. More planned. If someone implements my proposal today, they can already interoperate with Arcane/Atout, QQQQ/Quack/Q<, and Darius.

So I have no plans to make significant changes to the format that would break existing patches. It’s more about whether people agree with the name and the voltage values, and whether they have any interest in implementing it at all.
If a standard with different design goals gains traction in the future, I will certainly add support for it, but I do not plan to implement a more advanced hypothetical format with advanced features that have no established ecosystem of implementations to interact with.

I understand, just giving you my thoughts. I think the format is good as it is, I’d use it if I were to make a quantizer but since your Q modules are here I don’t know if I should :slight_smile:

1 Like

Updated the proposed specification with:

  • The format is only concerned with representing which semitones of any octave, split in twelve tones, are enabled or disabled. It carries no information about the tonic, nor about which octave it represents.

And of course I don’t want to shut down the conversation by having an implementation already in the wild. I’m just trying to figure out how to make my little ad hoc format play nice with the wider ecosystem.

1 Like

Also: if you would be interested in interoperating if the format carried a tonic, please say so. But for now I’m sticking to my initial proposal to avoid fostering bikeshedding a format I’m the only one to implement.

I implemented nearly the same thing in my unannounced (or so I thought) 12-TET quantizer.

I originally forced the root note to always be enabled, but have now changed this to be more consistent with your spec.

However, I don’t understand having the enable threshold just be greater than 0V. I’m using greater than 1V, to try and give a reasonable amount of voltage margin.

1 Like

Since there were no new replies I didn’t mention it, but I considered amending the original proposal to say that while modules are free to send the values they wish, and should make do with badly formed data, if one of the channels has a higher value than the rest, it can optionally be used to determine the tonic. What do you think about that?

Should cleaning noise be the recipient’s responsibility? It’s hard to come up with behaviors that please everyone and integrate well with hardware.

I would rather keep any optional extensions to the top four unused channels, since I just ignore them already.

I guess it’s just too many years of looking at electrical datasheets, with all their VOL’s, VOH’s, VIL’s, and VIH’s.

However, I have had issues with VCV Rack and comparing the really tiny floats that can happen right next to zero, so I try to avoid them at all cost.

Having both considered where I want to take my own collection next, and feedback, I’m proposing a 2nd revision. Please read the OP again!

Key changes:

  • 0.1V is the minimum
  • Channels can encode the data they want, including probabilities
  • For quantizers, enabled note is 8V, and the tonic is 10V if it is known
  • Modules are not guaranteed a specific format and should make do with whatever input they get

And here’s a table how I plan for things to be implemented in version 1.6.1 of my plugin:

Module Implementation
Arcane Enabled notes are 8V. No tonic information provided.
Atout Enabled notes are 8V. No tonic information provided.
Darius Anything above 0.1V is a valid quantization target.
Quatherina’s Quality Quad Quantizer Input: Anything above 0.1V is a valid quantization target. Output: Enabled notes are 8V. If the note on the Key knob is part of the current scale on the piano display, then it is sent as 10V.
Quack Same as above.
Q< Input only: Anything above 0.1V is a valid quantization target.
Quale Anything above 0.1V is a valid chord target in Scale > Chord. Enabled notes are 8V in Chord > Scale.
Modulus Salomonis Regis Anything above 0.1V is a valid quantization target.
Modulellus Salomonis Regis Anything above 0.1V is a valid quantization target.
Modulissimus Salomonis Regis Anything above 0.1V is a valid quantization target.