They are relative. The only time you will see jumping is:

1) When you load a Performance - the knobs move to programmed positions. This would be an intended jump for initialization
2) If you've programmed a SCENE button with an absolute superknob value - superknob and the linked assignable knobs can "jump". This would be an intended jump per programming.
3) If you press the superknob memory switches - these set to absolute values similar to SCENE (except dedicated switches not within a scene). Again, this would be by design
4) If you mix absolute controllers (like a foot controller) - more on that later

Wherever superknob is currently at and wherever the assignable knobs are at - if you start spinning knobs - the values will move relative _for the knob you're spinning_.

I say this because you could have Part 1 Assign 1 Knob linked to Common Assign Knob 1 which is linked to superknob. If you start spinning superknob - the Part 1 Assign Knob 1 will move (through Common Assign Knob 1) by command of superknob. If you then stop spinning superknob and move to spinning Part 1 Assign Knob 1 then you will take it away from the offset as controlled by superknob. Spinning the Part 1 Assign 1 knob will move the parameter relative to where it was left by superknob - and you start moving relative (yet away from superknob). If you then start spinning superknob - superknob itself will move relative to where it left off - but Part 1 Assign 1 knob will "snap" back under superknob control - which may be an abrupt movement. But note that you weren't spinning Part 1 Assign 1 knob when this abrupt change happened - this is just a consequence of taking the knob off course from superknob. So the knob you're spinning will always be relative to its position where it is left.

One thing to throw out there is that the foot controller if linked to superknob is a different controller than superknob. Superknob is a continuous controller and therefore it doesn't matter what the physical position of the knob is -- it will always act relative. The foot controller is different because it converts absolute rotational angles upon the controller's axle to absolute values for every angle (between 0-127). So if you spin superknob away from the foot controller's value (say the foot controller is at full heel which will be a value of 0), say you spin the superknob all the way clockwise to 127 - then move your foot slightly - it will "jump" to a low value since full heel = 0 absolutely and moving the pedal will register, "snap back" to 0 or a value slightly above. The foot controller isn't what you asked about - but it's one of those things that can cause non-relative behavior since the foot controller does not act on relativity. It works absolutely.

The knobs are endless encoders. Endless encoders do not have absolute positions, so they don't have the problem in the first place. It's an advantage over the comparable boards from Korg, Roland, Kurzweil.The knobs are always in the "right" place.

Perfect! Am I correct to assume that the knobs also work in the relative mode when sending MIDI CC messages to control other MIDI gear (e.g., soft synths)?

The knobs are endless encoders. Endless encoders do not have absolute positions, so they don't have the problem in the first place. It's an advantage over the comparable boards from Korg, Roland, Kurzweil.The knobs are always in the "right" place.

Endless encoders often still send absolute MIDI values by default. This means that if you were to use a Montage/MODX encoder to turn a virtual dial on a computer screen, the virtual dial would snap to the value indicated by the LED ring around the encoder.

An alternate mode of function is to have clockwise encoder rotation send one constant value (an "increment command") while counterclockwise rotation sends a different constant value (a "decrement command"). This way, an endless encoder can be used to control virtual knobs in an intuitive way: turning the encoder just a bit clockwise always turns the virtual knob just a bit clockwise as well (so long as the virtual knob isn't at its maximum position). Cubase supports relative MIDI messages.

There seem to be a few different ways of actually implementing the increment and decrement messages in MIDI, as evidenced by the options available in the configuration for the endless encoders of Arturia's Beatstep Pro controller:

• Absolute: turning the knobs sends everything from 0 to 127. This is the default
• Relative #1: clockwise sends 51%, counter-clockwise sends 50%
• Relative #2: clockwise sends 0%, counter-clockwise sends 100%
• Relative #3: clockwise sends 12%, counter-clockwise sends 13%

I'm not sure how Cubase's implementation works. The Montage and MODX manuals contain no relevant reference to "relative" or "absolute", and no one in this thread has mentioned the existence of any associated settings, so I assume that Montage/MODX always function in "absolute mode" seeing as that's the best default when some hardware and software doesn't support relative MIDI messages.

I've submitted this over at IdeaScale.

Out of curiosity - where do you see the discontinuity where the "knob" doesn't match the target parameter? Looking at your Ideascale I think the reason is NOT for "knobs" on the MODX/Montage control surface itself. Because these are able to internally keep track of where the knob is and "always" be in lock-step without drifting. Thereby realizing absolute control (even though, at the MIDI messaging level, they use absolute messaging). What the complaint/suggestion/wish is aimed at is when interfacing external gear - since it doesn't know what the internal values are and therefore there is a discontinuity between the first MIDI message (before and after).

Using MIDI protocol, I'm only aware of one way to do relative assignments. To load up a the registered parameter CC value first. Then use the INC and DEC command for relative movement. Only one parameter at a time can be handled like this (you can't set all parameters in "relative mode") - so you must preceded every change in target parameter with a MIDI command to load the registered parameter then issue the INC or DEC.

MODX/Montage only has a short list of items controlled this way.

a) Pitch Bend Sensitivity
b) Master Fine Tune
c) Master Coarse Tune

Are you aware of any other mechanism, in MIDI, to do relative parameter assignments than this? Because one thing any instrument has to deal with are the provisions (or limitations) of the protocol itself. If this is what you're asking for - increment/decrement using RPN - then your request is to add more parameters to the RPN list beyond a-c above.

There are multiple protocols out there for relative control over MIDI; for example, the Arturia Beatstep offers three different modes (as I mentioned earlier in the thread).

In my opinion, the most sensible way is to treat a value of 64 as "zero" or "no rotation". Rotating a bit clockwise would send a value of 65, a bit counterclockwise sends 63. Faster rotation sends values further out toward 127 or 0. This way, the relative control happens directly via MIDI CC with no need for RPN, and assignment to the various parameters on a softsynth is simple. As I understand it, the Arturia Keylab (a MIDI controller) operates in this way.

You mention items within the MODX/Montage that are controlled via INC/DEC, but I'm not sure that I follow the relevance. The goal here is for the MODX/Montage to be acting as master and sending information about encoder movement to external software.

Ok. I'm getting there.

Sending CC data from MODX/Montage to conform to established 3rd party relative mode interpretations of CC.

There's Akai's where CC data of 0x00 means no change in data (keep same value) CC data of 0x01-0x3F means increment by that value (0x01, decimal 1 means increment value by 1 through 0x3F decimal 63 means increment the value by 63). Turning the knob "super slow" clockwise would produce a CC data value of 0x01 and turning the knob with blazing speed clockwise would produce a CC data value of 0x3F. And CC data values of 0x40-0x7F would decrease the value by 128-(CC data value). So a CC data value of 0x40 (decimal 64) would decrease the value by 64 and would be a reaction to spinning a knob counter-clockwise with blazing speed. And a CC data value of 0x7F (decimal 127) would decrease the value by 1 as a reaction to "super slow" counter-clockwise rotation.

Arturia's take is to have a few different modes.

Mode 1 sends 0x3D-0x3F when turned counter-clockwise and 0x41-0x43 when turned clockwise. Arturia shows 0x00 means "neutral position" (this matches Akai) for each mode 1-3 and that a CC data value of 0x00 is sent between each non-neutral value. The manual doesn't spell out which value means "faster increase" or "faster decrease" like the Akai manual does. Moving on ...

Mode 2 sends 0x7D-0x7F when the knob is spun counter-clockwise. Each value a different rotational speed - but again not documented which values mean "fast" or "slow". And values 0x01-0x03 are for clockwise rotation. This mode is closest to being compatible with Akai - so maybe the values of "fast" and "slow" match Akai's where 0x7F = slowest decrease and 0x7D=fastest (at least for this range) decrease. And 0x01=slowest increase while 0x03=fastest increase (for this range).

Mode 3 sends 0x0D-0x0F when the knob is spun counter-clockwise. And 0x11-0x13 when the knob is spun clockwise. Not sure which of these values are "faster" or "slower" increases and decreases the way my reference documentation is vague.

Note that this "neutral position" between every value doesn't seem to apply to all Arturia hardware since I've seen threads with MIDI monitor dumps of Arturia hardware that didn't show this. Not all their docs show this either. I've jumped around a few docs to try to flesh out some missing information.

I'm not sure if there are more interpretations out there (beyond Akai and Arturia). Akai's interpretation (I have docs from 1995 - not saying it's the earliest) predates Arturia's 1999 founding.

Looks like Mainstage, Ableton Live, Cubase support the Akai-ish, Arturia-ish way of doing relative mode. Seems like reaper supports relative mode. Reaper and live claim support for several different relative variants. I think Cubase supports only one type (the "Akai" way). Another way to look at this is the "Mackie Control" way - which, by my notes, officially was created after Akai's. But it matches Akai/"2's complement".

Behringer has relative mode too - they use two values. 0x45 means increment and 0x01 means decrement. This is different than either Akai or Arturia because it's opposite polarity (interpretation). And also a different "spread" of the values. But generally similar in that the CC itself is used with new-fangled data values to indicate clockwise or counter-clockwise movement.

Speaking of Behringer - they have 3 modes in another product

relative-1 = "two's complement". Same as Akai's. CC data value of 0x7F = decrement by 1. data value of 0x01 = increment by 1. 0x00 = neutral value (no change)
relative-2 = "binary offset". 0x40 = neutral value (no change). 0x3F = decrement by 1 (0x3E = decrement by 2 .. and so on). 0x41 = increment by 1 (0x42 = inc by 2 ... and so on)
relative-3 = "sign and magnitude". Data bit 6 represents the sign (1=negative, 0=positive). only bit 6=1 wound be 0x40 meaning negative. only bit 6=0 would be 0x00 meaning positive. So 0x01 would mean inc by 1 (0x02 inc by 2). 0x00 is neutral (no inc or dec). 0x40 is also neutral (no inc or dec). 0x41 would mean dec by 1 (0x42 dec by 2).

... AND there are 14-bit versions of these relative modes too. Not that you're asking for more precision.

Doepher tries to do things in a slightly more standards way - but writing somewhat of their own book on the data value.

They send CC 0x60 (decimal 96) for data increment and CC 0x61 (decimal 97) for data decrement. And the data value of 0x00-0x7F represents the target CC value to increment or decrement. This is different than Montage/MODX's own use of increment/decrement - stuff I was talking about before. So Doepher's way - in full would be 0xBn (n=ch#, 0xB = CC) 0x60 (for increment) 0x25 (where 0x25, as an example, is the CC value to increment)

But anyways - that's the other way. You just bump up by one or down by one depending on CC 0x60 vs 0x61.

... given Cubase support's the Akai/Mackie Control relative mode - it seems like this would be the best bet for adoption given the affiliation with Steinberg. Maximum compatibility with everything out there would mean quite a kitchen sink of approaches.

Excellent research! Thanks for sharing all that data.

Personally, my own use would be either in Cubase or in VCV Rack which is easy for any programmer to extend with their own modules (or to modify existing open source modules to suit). So, it wouldn't make much difference to me even if Yamaha decided to skip all of that and make their own new method altogether. I assume Cubase support would be a given in any case (even if an update is required), and I'd be happy to do whatever work would be necessary to get things working properly in VCV Rack.

The Akai way is already supported by Cubase - so that'd be the way to go, I would think, in order to maximize the chance of adoption. Synergy between the request and what's already available from a sister organization at Steinberg.