Right, when you spin superknob the assignable knobs that are connected and react do not themselves transmit MIDI.

There are lots of times I wish they did.  At some point I asked for CCs to be a destination so I could use an assignable knobs as a source and output CC values as a result.   Having everything documented at once (all 72 assignable knobs) would probably flood MIDI 1.0 so being able to pick and choose would solve most of my use cases without flooding.

I don't know for sure, but I don't think M changes this.

In the case of Superknob controlled Assignable knobs you could cheat and just track superknob then have software "generate" CC responses that mirror the knobs.  Something like BOME or Ctrlr.  That doesn't account for all of the other controls that don't always transmit any MIDI.

I'm just offering there may be a subset of what you want available with some external help.

There's also DAW remote if you want a more 1:1 although that's far from what you asked for.  But may present another angle depending on what you're trying to accomplish.

Thank Jason for the info. I had assumed that when recording to Cubase via USB, all physical controls are recorded, otherwise, what would be the point of a so-called direct interface in Cubase? Please correct me here, as I'm sure I will have missed something.

Superknob is recorded so when you play that back, the connected assignable knobs follow as they should.

If you manually spin assignable knobs they will either send CC or SYSEX depending on the "mode" of the knobs.   Therefore, to record everything you need to be sure to enable sysex capture in Cubase.

Thanks Jason, and sorry for the late reply.

I'd like to clarify: Your aforementioned cc/sysex get sent out via USB, not 5 pin DIN, correct?

I'd like to clarify: Your aforementioned cc/sysex get sent out via USB, not 5 pin DIN, correct?

That depends on whether the MIDI IN/OUT parameter is set to 'MIDI' or 'USB'. See page 477 of the Ops doc.

MIDI IN/OUT

Selects the terminal(s) for transmitting and receiving MIDI messages.
Settings: MIDI, USB

Bad Mister's article MONTAGE MIDI SETTINGS EXPLAINED has some additional detail.

https://yamahasynth.com/learn/montage-series-synthesizers/settings-explained-montage-midi/

The messages that are generated by playing and moving controllers of MONTAGE come in two categories:

Combine that excerpt above with what you said earlier

Thank Jason for the info. I had assumed that when recording to Cubase via USB, all physical controls are recorded, otherwise, what would be the point of a so-called direct interface in Cubase? Please correct me here, as I'm sure I will have missed something.

All physical controls ARE recorded. As Jason said when you turn the Super Knob, a physical control, it gets recorded so that when that MIDI is played back the value can again be used to reproduce the original sound.

But turning the Super Knob does NOT turn the physical common knobs and they do not, even indirectly, turn the part knobs. Since the common and part knobs are not physically turned they do not generate a value that can be recorded.

It is the PHYSICAL movement of a controller that generates a value - not the 'logical' movement. The physical controls aren't automated so you can't move them via MIDI.

Excellent response, thanks for the very clear message.

There's a such thing as MIDI overflow where too many messages are being transmitted for hardware to keep up or even for the MIDI bus itself to accommodate all of these messages and still meet the intended timing.

This is part of the reason why when you spin Superknob not all of the knobs that also move send MIDI messages.  It would potentially and unnecessarily clog up the MIDI bus.  Also, if you're looking at the MIDI messages there would be a lot of data to sift through.  

Efficiency and "simplicity" is a good thing in this case.

Now there are instances where I wish I could force cascaded knobs to also send MIDI which is why I previously requested, for Montage classic, that CC messages could be assigned as a destination.  

I had a related problem when I was controlling my Fantom from my Kronos. By default, the Kronos transmits Every. Freaking. Message. As a result, the Fantom would just sit whimpering in the corner. I solved the problem by going into the performance I was using on the Kronos to control the Fantom and unchecking three pages full of checkboxes so that only note, mod wheel and a few other relevant messages were being sent. Then all was right with the world.

If the super knob caused cascading messages to be sent for all the things it can control, I imagine it would make the midi cables squeak. The fact that you can play back just the super knob and the Montage is smart enough to then operate the other parameters is a nice and efficient way of doing things.

You also don't spend an entire weekend debugging things. Not, you know, that this has ever happened to me...

If the super knob caused cascading messages to be sent for all the things it can control, I imagine it would make the midi cables squeak. The fact that you can play back just the super knob and the Montage is smart enough to then operate the other parameters is a nice and efficient way of doing things.

Well stated. The way I look at it is that MIDI is being captured for what the USER is doing and not what the instrument is doing internally.

If the user turns the super knob it is captured. If the user turns a part knob it is captured.

The idea being that if the user programs the superknob to control what a part knob does then the user generally isn't also going to be turning the part knobs manually. That sort of defeats the purpose of having the super knob control it.

But, if the user does manually turn a knob that the super knob controls it will get recorded. But there will also be a sudden 'jump' of parameters the next time the super knob is moved.

Jason's suggestion for a second mode that does capture the underlying changes is valid but then you would face the issue you mention above about needing to filtering out one level or the other because it wouldn't make sense to play midi that contains both the super knob movement and the underlying changes.

To be clear, I didn't want a mode where everything was transmitted.  I preferred a way to tell individual controllers (as in one by one in control assignments up to the limit) to send their positions even if as a result of its parent causing the change.

To be clear, I didn't want a mode where everything was transmitted.

Although I can see why you might have interpreted my comment like that I really make no inference at all as to how the mode might be implemented.

The main point I was making is that there will always be a conflict if both a super knob related instruction and a direct knob instruction are both played back. That conflict has the potential to be compounded if there are other controllers that could also have their 'implicit' motions recorded and played back.

Part of that conflict has to do with determining the correct order of playback for multiple control movements when those movements aren't made by moving the controls directly.

If a control is moved directly then it is rather simple to just record that event at the time it happens.

But if multiple controlled parameters are implicitely changed by moving the super knob then you could have one or more problems.

1. Does the instrument make ALL required changes to ALL parameters simultaneously before ANY of those changes can cause side effects? A thread based application operates sequentially - it has limited functionality for making multiple changes simultaneously within a protected 'freeze/lock' zone.

2. When the physical controllers are moved simultaneously the actual internal movements occur serially. But when the parameters are changed by the super knob they would have to be given a timestamp - either the same time stamp for each incremental movement of the super knob or a set of sequential timestamps in some order.

3. I seriously doubt if the current architecture could properly process large numbers of MIDI messages as 'simultaneous'.

I can see how it would be useful to be able to log the info about just what the resulting value of the parameters are when an assigned destination is manipulated by the super knob or other controller.

But I would have to agree that, as mentioned,  any such playback without appropriate filtering of, essentially, duplicate, commands is just asking for trouble. And I'd bet we would all agree there isn't yet available a useful method of finding and deleting the particulars commands that need attention.