Sorry if this has already been asked, but is there any way to have TWO supercontrols for a subcontrol that sends SysEx?

Question

When a fader is configured to send SysEx messages, the SysEx messages can have two variables L and V.  L can come from a Channel Changer super control (but can be used for any purpose whatsoever by the receiving device).  V must come from the control itself.  OK.

I would like to implement a button that sends a SysEx command with two variables, BOTH of which come from super controls.

So another way of asking my question is:  Can a control's SysEx V variable come from a super control as does its L variable?

If not, might you ever consider adding more possible externally-set variables to SysEx commands in addition to the single L variable?  Maybe M and N, etc?

Ha, I'm a beggar AND a chooser!

Thanks!

Steve

Comments

The Channel Changer supercontrol should NOT alter the V variable of the subcontrol. Are you sure that's what you're seeing? If you are, it's a bug that needs to be fixed ASAP. Then... adding other variables is definitely on the list of future features...

---

User says:

"Sorry, I wasn't clear.  No, the super control is definitely NOT changing the V variable.  I was asking if it possibly could.

I'm jazzed you'll possibly add more variables; I'll use them!  Especially if Variable L can come from Super Control A, and Variable M can come from Super Control B, etc.  Though I appreciate that it won't be trivially simple to implement the user interface for the feature."

---

You want the same supercontrol to change the L and the V? Why (or maybe "what?")?

---

No, multiple super controls, each controlling their own single variable within a SysEx message -- that would be the ideal.

If this were the case, you could have a single fader that sends a SysEx message when pressed.  But the exact message it sends would be modifiable by a group of other super controls.

The generic SyseEx message sent by the fader could be, for example:

Company ID, Product ID, Individual ID, Parameter Group, Parameter Number, Parameter Value.

The Company ID and Product ID wouldn't change, and so would be entered into the fader's MIDI as static hex bytes.  The Parameter Value would be the V variable, as now.  But the Individual ID, Parameter Group, and Parameter Number would be the variables L, M, and N, and these would be obtained from the settings of three Super Controls A, B, and C, respectively.  So you would "steer" the message to a specific parameter target using Super Controls A, B, and C, and then use the fader to send the value to the targeted parameter.

In this example there are two additional variables M and N beyond the currently available V and L.  But really, even just one additional variable M would help a great deal.  Any additional variables beyond that would very nice, but I don't mean to suggest I would be asking for the most general case where you could have any number of additional variables.  Just one or perhaps two more would be extremely flexible.

Sounds like you've already got this on the Features To Add Someday list, so I'll look forward to that!

Thanks

---

Thanks, so what would be a concrete use case? Meaning, with what MIDI target is this interesting, and in what situation?

---

I'm a hardware designer and I'm designing a USB/MIDI hardware product that digitizes the positions of expression pedals and footbuttons, and sends them over MIDI & USB as streams of CC messages.  It's similar to the old Lake Butler CFC-4 but using 3rd-party expression pedals and buttons.  The user can choose which MIDI channel & CC number each pedal or button sends, but I didn't want to burden the product with the cost of a HW editing interface because I can use MIDI Designer instead!  

So I'm using SysEx messages to change the internal parameters, and they all use the same basic SysEx message format, as described above, where a parameter is specified by the ID of the connected unit (among many), the parameter group (to organize parameters into smaller groups instead of a long flat list), and then the param number within the group.  So this yields a 21-bit parameter address!  Thought of course this address space is very sparsely populated.  Nevertheless there can be a great number of parameters.  Instead of trying cover the screen with a huge number of very small controls, I thought wouldn't be cool if you could "build" the SysEx message using multiple Super Controls to steer the SysEx to the correct parameter, and then a single fader is used to actually send the built SysEx message.  So I could use just 4 screen controls to adjust any one of 2^21 parameters!  It's just a screen-space conservation method, I suppose.

For queries, if you allowed wild-card characters in the responses, you could have controls that displayed only the steering bytes in the SysEx return messages, so they would act like parsers.  Sort of the reverse process of building the message; these would "un-build" a response message.

It's really just a big thought experiment, but once I got started I had to find out how much might be possible either now or maybe in the foreseeable future.

I know Cycling 74's Max can do all manner of tweaky things like this, but it seems like too much to ask an entire user group to use Max as a device editor/librarian.  MIDI Designer will be the recommended choice, so I need to design the product's parameter editing methods to match MD's capabilities.

---

The wild card case is slightly obscure, but the multiple variables case is relevant, and part of the future of MD (hoping we get there soon): being able to adjust the Data1 on normal control change messages, plus the MIDI Max, Min, and even default are on the list of stuff to do at some point. All coming at some point.

So you can see how that would expand out to sysex pretty easily.

Wildcards... we'd have to discuss exactly how that works or doesn't. If the design-time UI implications are not that big, it's doable. God knows, we do have the bytes ;)

---

I totally agree with stevenchristensen and see 100% an extremely good use for this. Each Roland key board has 4 partials with say 100+ parameters. If you have only “V” in the sysex message  then you need to create 4 x 100 controls to get stuff going. I assume using  “L” would cut this to 100 controls "only". Good... , that already works in MDP I assume. But situation gets complicated... I have 4 tracks sections so without L and V we would deal with 4x4x100 controls so the “L” from supper would take care of one multiplicity 4x100 the L2 or A or B would drop the number of controls to manageable 100 controls. Definitely see space  for L2 from the second super control. Another example is Novation Matrix where you have 20 destination each with 4 parameters and then you have 8 macros each with 4 slots meaning 4x4x8 + 4x20. so there are a lot of situations where you deal with something A * B * C controls setup each multiplier is one extra supper control with L1 L2 ... I did the layout with 4x4x8 + 4x20 controls and believe I have a lot of problems with presets memory not working properly and speed of the layout.

---

Sorry, so just to be clear about what we're talking about again: we want more variables for supercontrols to modify sysex, that work exactly like L and V? Do they need to be multiple byte (like V) or can they be one byte (like L)? THANKS!