The MIDI control surface workflow improvement thread

Cubase
,
1

Hello to all,

For your consideration:

The purpose of this thread is to get as many smart people as possible who know way more than I do to chime in and put as much helpful information as possible into this thread for the following purposes:

  • To take what we know about MIDI controllers and use it to help each other build the best workflow possible.

  • To highlight the specifics of what we still need, and to lay out the exact measures for the Steinberg developers to help us in upcoming releases to achieve the goal of having the most robust, tactile, seamless workflow with MIDI controllers (and perhaps Eucon control surfaces) to achieve the best workflow possible.

  • To make it as easy as possible for average users like myself to understand the steps required to build a workflow with MIDI controllers that makes their lives in Cubase as optimal as possible.

For this thread, let’s treat it like a system. As people give their input, I’d like to arrange what we learn as a wiki so that we can use it as a system for success instead of “every man for himself,” trying to scour the forums and internet for answers about why they can’t achieve the workflow they desire.

If the workflow to be desired is not there yet (which in many cases will be true), let’s be specific about tangible step-by-step solutions that the devs can take to make it happen, rather than leaving it up to them to figure out what we want and need. If we can present them with a solid structure of workflow information to build upon, they can point their sites in those directions.

Points of interest (please expand as necessary):

  1. How to control and map plugin parameters as easily as possible while toggling from track to track and keeping the workflow from going off course (or hampering or impeding the workflow).

  2. How to build an optimized EQ controller with a MIDI device.

  3. Outlining specific workflows that may be foreign to users but can be taught as a system through a series of configurations and physical steps.

  4. Helping each other with more advanced and technical requirements (scripts, Java, encoder modes, etc).

Let’s come together and share as much complicated information as possible, breaking it down into easier information in one thread that everybody can digest, including the devs.

1 Like
2

While I do love the idea, I’m afraid we’re asking to map an ocean of possibilities here. Many times I’ve thought of starting a thread where we would discuss principles of designing a MIDI remote, in the vein of “I give you 8 knobs to twist. What do you assign to them? How can you design a complex web of functions for these 8 knobs that remains intuitive, quick and easy to navigate?”. But there are sooooo soooo many possibilities, and each user is unique and follows a completely different workflow from the next user.

That said. I will kick this off by discussing your 4 points.

  1. So far, I’m getting pretty good results (for me) with track based insert control. My idea is:
  • Have a page with Parameters 1 to n assigned, for my controller of n knobs and faders. This controls the plug-in in focus, of the currently selected track. I also have Next/Previous Track on the same page, and a Next/Previous plug-in, so that I can quickly change parameters without touching the mouse.

One thing that could be improved here is: Either have the plug-in window that has “control focus” brought to the front automatically when it’s being controlled (when the next plug-in command is given), OR have a suite of separate On/Off, Bypass, Edit, Load commands for each one of the 16 slots.

  1. It depends on how many knobs and buttons we have at our disposal, and the EQ in question. In my opinion, one needs at least 4 knobs and 4 buttons for the stock Strip EQ. 1 button for On/Off, 1 for Frequency, 1 for Gain, 1 for Q. If there are more buttons, 1 could control Filter Type, 1 could control Bypass, etc etc…

  2. That would be interesting.

1 Like
3

Good point about it being an ocean of possibilities, so perhaps let’s assume one encoder only for a moment.
Once we can establish a single, workable solution that has the following functions, the user could take the concept and spread it out over as many encoders as they have (8, 16, or more):

  1. If the encoder is endless, what encoder setting should be made in the utility that was provided by the manufacturer?

  2. What parameter does the user have to set in Cubase to make the endless encoder work efficiently and optimally?
    A) Coarse control vs Fine Control (Edit: And what constitutes the scaling between values)
    B) How does the user toggle between these modes (push encoder vs another button)?
    C) If the encoder has LED lights for the position (feedback), what protocol, settings, etc are needed

  3. Should there be a new open-source protocol for visual feedback of parameters for such encoders or do we already have this technology available to the public?

  4. Specifying a solution between a basic standard encoder vs an endless encoder.

  5. How does the encoder change values from track to track, and is it:
    A) Project setting
    B) Global setting

4

  1. Probably INC/DEC, since it’s a relative one.

  2. A) I don’t know, neither do I believe it’s possible yet, to have Coarse/Normal/Fine. If we could have this, it would be wonderful! B) Since it’s not there yet (I’m speaking about the Surface Editor, people can emulate this behaviour (fine, coarse) in scripts, but then there’s a problem with values going out to the hardware controller for LED feedback etc be different than they should…
    C) It depends on the hardware. In the very worst case, you can make a lamp that transmits the message that the device wants to hear, so that the LEDS work. But, again, a transformation might be needed, it’s not a given that the device wants to receive a CC x with values 0-127.

    1. .5. I don’t have the slightest idea.

One thing I still don’t understand even though @mlib kindly tried to explain it to me the other day, is: Who controls the absolute size of a parameter increase? Is it the plug-in? Is it the controller? None of the two? The same encoder is very sensitive in some plug-ins (e.g. a 4-8-10-20 compressor ratio, two clicks might make me miss the 10 setting) and very insensitive in other plug-ins (I have to turn turn turn turn to get a 1dB increase.) So, it would make sense to have Fine/Coarse modifiers that we use when we want, if we see that a parameter’s rate of change is not going as fast/slow as we’d like.

1 Like
5

Thank you @ggmanestraki for helping me get this thread going, by the way! Let me riff off of what you said and throw it out there so that we can get minds working:

When we think about encoders, some have LED lights, some have LCD screens (sort of like an MPC X), and some have no feedback at all (i.e, Arturia Minilab mk2). So it feels like 3 separate systems could be established for these 3 variables. We could say “if” LED light, then this. IF LCD screen, then which device and what protocol does it accept? If no feedback, ignore feedback since it’s moot. Or, would the feedback be on a tablet or monitor? Again, just throwing these things out there so that we can eliminate certain things, embrace others, or break it down into separate solutions and take all of it on (whatever happens in this thread).

When discussing encoder feedback, the variables I’m seeing so far are:

  1. The label of the encoder (what it does, i.e., attack, release, sustain)
  2. The value of the encoder (the parameter)
  3. How many steps the encoder moves when you turn it

I think this thread will help me (and some others) come to terms with what is already possible, what doesn’t make sense to implement, and what kind of system the users can learn (adapt) to make these solutions work for them. Sort of like learning to fly a plane - somebody might want to fly a plane however they want, but it might be better to learn to fly it a certain way for efficiency and safety and to adhere to certain basic standards.

I think we might also be able to come to a basic agreement as to what scales are acceptable when turning a knob or fader. Can the standard be .5db increments? If we were using a real EQ or compressor, would it have 1db increments or would it have .1db increments? Can we live with .5db or do we need .1db? .01db? If we need it to be user-specific, what kinds of real-world solutions could a Steinberg developer implement into a scaling system that could be toggled by the user and not get us into the weeds?

1 Like
6

I believe all of this is possible with scripting. Screens get the parameter’s name as a label, which can be customized in the Remote Control Editor for each plug-in. The actual value is transmitted back to the device (in the surface editor too, if the appropriate checkbox is ticked). The LEDs, they grab the value and act accordingly.

But the deal is, all this is specific to the device. Some devices specifically state in the manual the exact values and CCs that the device uses to control LEDs, LED modes, colors, etc. etc… Others don’t. In any case, there are quite a lot of people in this forum that have deep knowledge and do wonders with the scripts. If you create a thread with a specific problem, they’ll provide a solution really fast.

1 Like
7

Another matter that is somewhat relevant to the spirit of “workflow improvement” is MIDI remote design, on a theoretical level.

For example, as a user of the Surface Editor, I find myself creating nearly identical pages so that I can simulate “Shift” states. I have 8 encoders, I want them to control EQ. Great. Let’s map it out.
The positions are like so.

Encoder Layout and Numbers
Column A Column B
1 2
3 4
5 6
7 8
Page A Page B
Encoder / Movement ~~~~~ Function Encoder / Movement ~~~~~ Function
1 / Turn ~~~~~ Band 1 Freq 1 / Turn ~~~~~ Band 1 Q
2 / Turn ~~~~~ Band 1 Gain 2 / Turn ~~~~~ Band 1 Filter Type
3 / Turn ~~~~~ Band 2 Freq 3 / Turn ~~~~~ Band 2 Q
4 / Turn ~~~~~ Band 2 Gain 4 / Turn ~~~~~ Band 2 Filter Type
5 / Turn ~~~~~ Band 3 Freq 5 / Turn ~~~~~ Band 3 Q
6 / Turn ~~~~~ Band 3 Gain 6/ Turn ~~~~~ Band 3 Filter Type
7 / Turn ~~~~~ Band 4 Freq 7 / Turn ~~~~~ Band 4 Q
8 / Turn ~~~~~ Band 4 Gain 8 / Turn ~~~~~ Band 4 Filter Type
1 / Push ~~~~~ Band 1 On/Off 1 / Push ~~~~~ Band 1 On/Off
2 / Push ~~~~~ To page B 2 / Push ~~~~~ To page A
3 / Push ~~~~~ Band 2 On/Off 3 / Push ~~~~~ Band 2 On/Off
4 / Push ~~~~~ To page B 4 / Push ~~~~~ To page A
5 / Push ~~~~~ Band 3 On/Off 5 / Push ~~~~~ Band 3 On/Off
6 / Push ~~~~~ To page B 6 / Push ~~~~~ To page A
7 / Push ~~~~~ Band 4 On/Off 7 / Push ~~~~~ Band 4 On/Off
8 / Push ~~~~~ To page B 8 / Push ~~~~~ To page A

So, in page A we control frequency and gain, in page B Q and Filter Type, and we switch between the two pages by pressing any encoder on the right column.

Now. Is this better than having 4 pages, “Freq”, “Q”, “Gain”, “Type”, and use just 4 encoders, one per band, and 4 buttons, like so:

Button Page Freq Page Q Page Gain PageFilter Type
Button A None or Reload Page Freq Page Freq Page Freq
Button B Q None or Reload Q Q
Button C Gain Gain None or Reload Gain
Button D Filter Type Filter Type Filter Type None or Reload

And even then, maybe it’s better to use scripting and use sub-pages?
Or maybe there could be a “Global” assignment above pages, that keeps the assignment for all pages? Like a permanent shift button? Or a modifier? Or even worse, assign an encoder for this, to scroll through remote pages, parameter banks, plug-in control banks?

The possibilities are endless. But what does actually work? Intuitively, efficiently? That’s the big question.

1 Like
8

Excellent post @ggmanestraki ! Now we’re talking!

Did I read in another thread that you have the Midi Fighter Twister? I just picked up the Midi Fighter Twister so let’s use that as the example if you don’t mind. :wink:
Since the Midi Fighter Twister has 16 encoders that can also be pressed to change the CC, either by toggling or holding them down, we could use that as a default hardware system for the theoretical outline. Then everybody who wants the workflow can pick one up and they’d have the workflow outline here as the guide.
I was thinking along the same thought path that you illustrated in your “Page A, Page B” layout:

  • Frequency and gain use the first left side 8 knobs on what we could call page A.

  • User then toggles to what we could call “page B” (as opposed to bank B which would switch all 16 encoders) by pressing the encoder down to convert those knobs to control the Q and filter type.
    Example: To change the Q of band 3, user presses band 3 frequency encoder. When user is done adjusting the Q, user presses encoder again to toggle back to frequency control.

  • In Midi Fighter Utility, user must first set encoders to “CC toggle” mode instead of “CC hold,” unless user wants to hold down the encoder while turning the knob to adjust the Q, then let go for knob function to return to previous state.

  • In Midi Fighter Utility, set “Encoder Midi type” to “ENC 3FH/41H” to make it relative mode, correct?

  • In Midi Fighter Utility, enable the “has Detent” checkbox for the encoder so that the LED is up the middle, like an EQ knob would be in nominal position.

How about for controllers that have 16 encoders such as the Midi Fighter Twister, the other 8 encoders on the right side control compression? What would be an optimized theoretical arrangement for compressor parameters, in your opinion? I can edit this post later to continue the steps once we figure out what a good workflow would be.
Also, if you can give the info needed to configure the midi remote in Cubase to work with this, that’d be awesome!

9

I don’t have the twister. I like it a lot though, and I always keep an eye out if a good one would pop up used. For the time being, I went with the Behringer X Touch compact, because I thought I could really do with the motorized faders. It’s working fine, really, and it’s giving me pleasant headaches of “how to maximize control potency, but keep things intuitive and simple”. That’s an everyday struggle. I have to test what I thought was a really great idea to see if it’s barely useful at all.

That being said. In my case, with the behringer, I have two “layers”. Press A on the device, it’s one set of messages. Press B, it’s another set. Sounds familiar, eh? :wink:

Personally I went with the brute force method of creating a surface script that depicts both A and B at the same time. I’m seeing double the controls that the hardware controller has.

In the twister’s case, if you opt for the push of the encoder to toggle CCs (from the twister’s side, no Cubase yet) it could be set up as a 32 encoder device, with no push. But I believe that the twister also has banks? In that case, would it be manageable to have 4x32 banks on screen at any time and still know what’s what? That’s the greedy approach, when we’re looking for the maximum amount of controls to fit to our remote.

On the other hand, 4x16 is 64, much more manageable. Ok, maybe program 1 bank (if it’s possible to program just one of the banks), to switch between two sets of CCs, exclusively for the EQ, IF we stick to that method. The remote in cubase would have 3x16 + 32 = 80 parameters in total.

This is another major point. Personally, I’m not tweaking blind, especially if I’m not sure which plug-in has focus. I want to see the plug on screen, and I want the hardware controls to follow the plug-in’s layout, from top to bottom, and from left to right, as if I was reading. However, not all plug-ins’ default parameters are laid out that way. So, I have to go into the RCE (remote control editor) of the plug-in, and swap things around until it fits me. So if a compressor has a huge input knob on the very left, that’s what my leftmost encoder controls. If a different compressor has a tiny ratio knob on the very left instead, that’s what my leftmost encoder controls.

(Somebody should make a “plug-in Defacer” that would cause knobs and sliders of the plugins’ GUI to move around automatically to match the shape of your controller, skeuomorphically. :sweat_smile:)

In my opinion, first comes the physical device. How many controls you can realistically manage on the unit. Then, once the number is decided, you can create a suface in Cubase (or by script). And the final thing is to explore workflow.

For example, you have 16 encoders in a square. If you wanted a page to control sends, what would suit you?

  • A 2 channel, 2 row control of all eight send levels, with Pre/Post on encoder push, that uses banks to get to other channels?
Send Send Send Send
Channel 1 1 2 3 4
Channel 1 5 6 7 8
Channel 2 1 2 3 4
Channel 2 5 6 7 8
  • A 4 channel, 4 send mixer, vertically, that uses a second page for sends 5-8?
Channel 1 Channel 2 Channel 3 Channel 4
Send 1 1 1 1
Send 2 2 2 2
Send 3 3 3 3
Send 4 4 4 4
  • A 16 channel mixer of just 1 send, in a web of 8 pages in total for each one?
Channel Channel Channel Channel
Send 1 1 2 3 4
Send 1 5 6 7 8
Send 1 9 10 11 12
Send 1 13 14 15 16

It’s not an easy answer for me. I try lots of stuff like that until I settle to a method that seems to work better than the others. It takes a lot of time. I guess scripting could help speed things up, but I’m fairly useless at it. It takes me more time to try and formulate something in a script than to brute force it in the surface editor. :face_with_head_bandage:

1 Like
10

I’ll probably chime in later again with some more thoughts and ideas.
For now, I’ll share my Midi Fighter Twister setup.
image
(This is a stock photo)
The second page on the Twister is dedicated to Quick Controls.

Until Steinberg has sorted out the rounding bug and feedback echoes (both these issues have been discussed in the forums) I am resorting to using the legacy Generic Remote.

Not sure if this is slightly off topic, but when MIDI Remote API was announced I was super excited seeing how it has the potential of becoming both an advanced tool for configuring controllers, but also as an advanced version of a PLE. If the API allowed the same data to be accessed as the PLE, it would become proper, super-charged Logical- and Macro Editor. Showing/hiding tracks and channels using more specific criteria in JS is one thing it could excel in. (Especially if the script can send multiple commands to Cubase before it updates its UI.)

3 Likes
11

I find myself using the MIDI Remote for some and the Generic Remote for other buttons/dials on the same hardware controller :rofl:

12

I share your desire, but am afraid that this forum doesn’t lend itself well to the stated objective.

What you’re after is incredibly wide coverage of multiple dimensions. In math terms, that would be a multi-dimensional matrix, where each cell represents a different combination of environment and individual priorities and preferences.

Some of the axes/dimensions would include (sometimes this is also thought of as a taxonomy):

  • different hardware controllers
    • different types of controls (buttons, knobs, pads, encoders, faders, touch strips, leds, displays, etc
      • with different capabilities (motorized, touch sensitive, message types being sent/received, etc
  • different musical workflows
    • composing , arranging, sound design, mixing, etc. plus a bunch of hybrid workflows
  • different parts of the Cubase environment
    • Cubase itself (one shot commands, the mixer and other stateful controls and preferences, monitoring data feeds, etc)
    • instrument plugins (audio generating instruments, Midi generating instruments, etc
    • fx plugins (audio producing, midi generating, visualizers, plugin chainers, etc)
    • track and channel types (group, instrument, audio, midi, tempo, arranger, etc)
    • personal preferences in style of working and mental models by individual music makers (as Cubase product managers and developers can attest much better than me, it’s crazy how many different ways people use Cubase)

Organizing conversations and resulting tips and techniques into their right matrix/taxonomy boxes would be pretty much mandatory to make them more practical and approachable for more people.

For example, much of the conversation of using midi controllers as mixing consoles is relatively absent in my current workflow. I use my midi controllers for plugin parameter control and overall Cubase control (transport, zooming, track selection, preference setting, etc). Mixing (levels, panning, eq, etc) is more about drawing lines/curves or entering numbers for me.

I’m always in awe of how other music makers work so very different from me. But I suspect those differences are actually part of our musical uniqueness, because different workflows are also related to making different music.

So I think, it would probably require a separate online discussion and documentation environment than this (or any) forum software. And such an online environment should be easy enough that total non programmers can easily fully participate. So git isn’t really a good thing for many people. A real wiki might be better. But even that doesn’t fully excite me as the right platform for this undertaking.

First step would definitely have to be a very good taxonomy. And musical taxonomies are notoriously difficult to standardize. But I’m game to participate in such an attempt.

2 Likes
13

Yeah you’re totally right, actually. I ask these questions to see if there’s any way to make sense of it all. I want a system that I can learn, that works, and then I’ll buy whatever that thing is.

I think you brought up the elephant in the room which is that people all want to work so differently, rather than adapt to an established system that works well. My brain must be different in that regard - I’m willing to learn a system, just like an engineer would learn how to use a console. The engineer couldn’t move the EQ knobs around to fit their workflow - they’d just learn where everything was, how it worked, and developed muscle memory.

My goal is to do that, but with MIDI controls. If not MIDI, maybe something similar.

In regards to the different setups that people have, I would propose different systems that are not related, then users can decide which system fits their workflow the best. System 1, system 2, etc.

1 Like