Incoming sysex lets MD send out sysex from super controlled controls unintentionally

Question

MIDI Target Manufacturer(s): Roland

I made a layout, double-checked all controls functionality (working with sysex single parameter changes) and they all work fine.

Then I created a button that would call a set of sound data from the target synth as one long sysex message. A streambyter input rule would then look up each value from the incoming message, re-create the according single parameter change again and send it to the layout. I double-checked each single control in the layout and they all adapt perfect to changed settings in the target device. So both the button for calling data as well as the input rule seem to work fine. I also looked into the log, which confirmed that data sent into the layout are correct.

However I have a few cases, where the sending control A has a supercontrol B, which is again supercontrolled by C (e.g. by a knob for grouping two buttons). Now when I send a single parameter change from the target device to MD for the function controlled by A, all controls in the supercontrol chain adapt properly to changes.

But if I call the settings from the target using the above mentioned button, where I get a long list of values, all the controls of that described chain of supercontrols start to get crazy, jump back and forth and thus create a couple new sysex messages, which are then sent back to the target.

This is of course not intended at all. The layout should just receive the data, adapt to them and not send any new messages back.

I add a screenshot from MIDI Monitor, which I use on my computer, where all devices are connected to. The first message is from the button in the layout calling the data set from the target. The second message is the (long) answer from the target device. All following messages are created and sent from the layout back unintentionally. The last three bytes before the F7 here are parameter number, parameter value and checksum. As you can see some parameters are sent repeatedly with different values.

Any idea what the problem could be? Normally when the layout receives data and adapts to them, nothing should be sent out in return.

I should probably add, that the amount of unintentionally sent data varies each time. Sometimes it is a lot more than shown in the screenshot. One single parameter can be changed 5 or 6 times.

Images

Bildschirmfoto 2021-11-05 um 20.04.39.png

Answer 1

Are all the problem controls either super or sub controls?  If so, it is not the sysex that is causing the problem, it is just "normal" super-sub relationships.

For sub backdriving a supercontrol, somewhere on the Q&A site in the past year is a discussion about how to prevent feedback from sub control to super control.  I believe we had a bug that Dan fixed in certain back drive cases.  Quick search didn't find it, but I will keep looking.  (I think, but am not sure, that if a super has two subs, then changing one will not feedback, so precluding the feedback might be as simple as adding a "dummy" subcontrol that doesn't send any data, just dampers the feedback.)

If you are setting a supercontrol, there is no way to stop it normally feeding down the chain.  I have had to live with this on a few of my layouts.  Since it is sending the same data to the synth that it received, is not an issue.  But I can see how it could be in some cases.

If data output during the sysex processing is causing real problems, think about adding a subcontrol to the retrieve data control that turns on a SB rule to stop all layout midi output temporarily, until the controls settle down.

Comments

Thanks! But it is actually the other way around: I have a hidden knob, that handles the MIDI data and thus responds from incoming MIDI. The knob is controlled by a group of (again hidden) buttons, that are controlled by another group of visible buttons. These are the ones, that I use to operate (they supercontrol other things, too, namely for showing/hiding panels). So what I want is that the hidden group of buttons respond to the hidden knob (their sub) and finally the visible button group responds to the hidden button group. Honestly I had repeatedly problems, when a button group supercontrolls a knob and when the knob is changed via MIDI, the button group does not respond properly as well. Any hints in that direction?

---

So I suspect it is the super - sub relationship that is causing you issues.

For reliable behavior, never rely on a sub control to drive a super control to a desired position.  The control flow works best top to bottom.  (I know some have had success back driving, but it can be a problem source, and I would argue an unsupported feature.)

Build your relationships top to bottom.  At the top is the control that receives the inbound sysex.  This might require duplicating some controls at the top and the bottom of the control string.  This works for me in multiple complex layouts.

The one side effect of duplicating a control a the top and bottom is that the control will send the data back to the synth during sysex reception.  This is where you can temporarily block outbound sysex if needed.

---

Thanks for your thoughts! By the way I got the first part sorted: the unintentional sending of data after receiving data! The hidden group of buttons, which are controlled by the visible buttons and control the MIDI knob were not grouped. So once I installed another knob as a supercontrol for those buttons, the weird behavior stopped completely.
Nevertheless I don't get the MIDI knob at the end of the supercontrol chain feeding back to the hidden button group and then to the visible button group at the beginning of the chain. I will make a few more tests.

---

I meanwhile found a solid solution for the problem: I have never used "Supercontrols send own values" so far. But I found that it is the best solution here. Now I can use a knob as a supercontrol to group the buttons and t the same time to send the necessary MIDI data. And when receiving MIDI data, the knob will respond and so will the buttons. I can delete all the other instances of the supercontrol chain. I just need to make sure, that all other supercontrols in the layout (e.g. knobs to group other buttons) don't send data unintentionally. I simply set them to random CC and installed a streambyter output rule, that blocks all CCs. Because CC is not used in this layout, it is all sysex. Thanks again for the discussion, which set my mind to the right direction!

---

re: "Nevertheless I don't get the MIDI knob at the end of the supercontrol chain feeding back to the hidden button group and then to the visible button group at the beginning of the chain. I will make a few more tests."

I believe this is specifically excluded sub to super feedback case, due to some problems it causes.

Answer 2

Are all the problem controls either super or sub controls?  If so, it is not the sysex that is causing the problem, it is just "normal" super-sub relationships.

For sub backdriving a supercontrol, somewhere on the Q&A site in the past year is a discussion about how to prevent feedback from sub control to super control.  I believe we had a bug that Dan fixed in certain back drive cases.  Quick search didn't find it, but I will keep looking.  (I think, but am not sure, that if a super has two subs, then changing one will not feedback, so precluding the feedback might be as simple as adding a "dummy" subcontrol that doesn't send any data, just dampers the feedback.)

If you are setting a supercontrol, there is no way to stop it normally feeding down the chain.  I have had to live with this on a few of my layouts.  Since it is sending the same data to the synth that it received, is not an issue.  But I can see how it could be in some cases.

If data output during the sysex processing is causing real problems, think about adding a subcontrol to the retrieve data control that turns on a SB rule to stop all layout midi output temporarily, until the controls settle down.