CCpotentiometer with MSB and LSB

[MarcosGogo]

Is your feature request related to a problem? Please describe. Hi Peter. I'm trying to make a midi controller for a Hardware DAW that can be controlled by MCU protocol. I've already managed to implement several functions with your library. This hardware DAW has a parameter that I was able to control with V-POT command via encoder. But I would like to control the internal parameter, which is controlled by the V-Pot, with an analog potentiometer, just like it is controled with the hardware physical analog potentiometers, so no V-POT. I imagine this function is outside the Mackie protocol. This Daw has a tablet app that can control the DAW via USB, and I found a way to monitor midi messages. So i believe i can find a way to control this parameter even outside the MCU protocol. I ended up discovering that this parameter is controlled by the midi message "Control Change MSB + LSB". As I understand it appears to be a 14bit CC. I searched here on the Control Surface git hub and found some posts with CC14bits implementation by ContinuousCCSender14. I entered the code with the same midi addresses that I found in the midi monitor with the official app, and got the exact same monitoring, with my controller, in the midi monitor. Unfortunately when I plugged my controller into the DAW, it doesn't control anything. The other functions work. I would like to understand if I might be doing something wrong. Do you imagine what could be happening?

The addresses I want to map are as follows:

Channel 1: Control Change MSB - CC#24 ch1 [Hex 18 (0x18)] ------------------LSB - CC#56 ch1 [Hex 38 (0x38)]

Channe 2: Control Change MSB - CC#25 ch1 [Hex 18 (0x19)] ------------------LSB - CC#57 ch1 [Hex 38 (0x39)]

One thing I found strange is that this specific Control Change MSB address I'm trying to implement, is the exact same midi address for SELECT from the MCU protocol (SELECT_1 = 0x18). I know they are different controls, one is Control Change and the other is Midi Note, but I ask if there can be some conflict because they share the same midi address.

My Setup:

• Teensy 2.0 (clone)
• Control Surface new-input branch downloaded via zip Git Hub green code link.

 #include <Control_Surface.h> // Include the Control Surface library

// Instantiate a MIDI over USB interface.
USBMIDI_Interface midi;

class CC14Potentiometer : public MIDIFilteredAnalog<ContinuousCCSender14<10>> {
  public:
    CC14Potentiometer(pin_t analogPin, MIDIAddress address)
      : MIDIFilteredAnalog(analogPin, address, {}) {}
};

// Instantiate a CC14Potentiometer object
CC14Potentiometer potentiometer [] = {
  {A1,                                   // Analog pin connected to potentiometer
  0x18}, // Channel 1
  {A3,
  0x19}, // Channel 2
};

PBPotentiometer potentiometers [] = {    //FADER
  {A0,        // Analog pin connected to potentiometer
  MCU::VOLUME_1}, // MIDI Channel 1
 {A2,
  MCU::VOLUME_2},
};

NoteButton button [] = {     
  {1,                       
  MCU::SELECT_1},              
  {0,
  MCU::SELECT_2},

};

NoteLED led [] = {  //LED  

  {9,
  MCU::SELECT_1},
  {14,
  MCU::SELECT_2},

};

void setup() {
  Control_Surface.begin(); // Initialize Control Surface
  for (auto &potentiometer : potentiometers)  // Inversor de potenciometros global linha 1
    potentiometer.invert();                   // Inversor de potenciometros global linha 2
   // potentiometers[0 ].invert();            // 0Inversor de potenciometro individual
}

void loop() {
  Control_Surface.loop(); // Update the Control Surface

}

[tttapa]

Do you imagine what could be happening?

One possible reason could be that the hardware DAW doesn't have a working USB driver for the Teensy 2.0. Can you test if the DAW “sees” the Teensy, or if it receives any messages at all?

Does the following work?

void setup() {}

void loop() {
  const unsigned long interval = 100;
  static unsigned long prev_tick = millis() - interval;
  const uint16_t delta = 8;
  static uint16_t value = 0;
  const uint8_t address = 24;

  if (millis() - prev_tick > interval) {
    usbMIDI.sendControlChange(address + 0x00, (value >> 7) & 0x7f, 1);
    usbMIDI.sendControlChange(address + 0x20, (value >> 0) & 0x7f, 1);
    value += delta;
    if (value >= 16384)
      value = 0;
    prev_tick += interval;
  }
  while (usbMIDI.read());
}

One thing I found strange is that this specific Control Change MSB address I'm trying to implement, is the exact same midi address for SELECT from the MCU protocol (SELECT_1 = 0x18). I know they are different controls, one is Control Change and the other is Midi Note, but I ask if there can be some conflict because they share the same midi address.

No, there shouldn't be any conflicts, MIDI Control Change and Note On/Off have different address spaces.

Teensy 2.0 (clone)

I have never personally tested the MIDI over USB implementation for the Teensy 2.0, it's just adapted from the Teensy core implementation, but I don't know if all configuration is 100% correct. That's why I posted the test sketch above to try the standard Teensy usbMIDI library without Control Surface, so you know where the problem lies.

[MarcosGogo]

One possible reason could be that the hardware DAW doesn't have a working USB driver for the Teensy 2.0. Can you test if the DAW “sees” the Teensy, or if it receives any messages at all?

Yes it seens to work properly, teensy 2.0 midi over usb seens to work, not sure if 100%. Daw recognize teensy as usb class compliant and I can control a lot of function, like volume fader, mute, solo, select etc. I have some problems with some leds callback, but i will open another post for that.

I have never personally tested the MIDI over USB implementation for the Teensy 2.0, it's just adapted from the Teensy core implementation, but I don't know if all configuration is 100% correct. That's why I posted the test sketch above to try the standard Teensy usbMIDI library without Control Surface, so you know where the problem lies.

I will try to test tonight. I need to download and include another library, and delete "include ", or just update my code under "void loop" with your sketch?

Thanks so much for help.

[tttapa]

I will try to test tonight. I need to download and include another library, and delete "include ", or just update my code under "void loop" with your sketch?

The code I posted is the full sketch, so just open a new, blank sketch in the Arduino IDE and paste that code. You don't need any libraries, just make sure that you have the “MIDI” USB type selected in the Tools menu.

[MarcosGogo]

I will try to test tonight. I need to download and include another library, and delete "include ", or just update my code under "void loop" with your sketch?

The code I posted is the full sketch, so just open a new, blank sketch in the Arduino IDE and paste that code. You don't need any libraries, just make sure that you have the “MIDI” USB type selected in the Tools menu.

Ok Understand, I wll test tonight. How could i know if test work correctly? I have just see if compile without erros?

[tttapa]

How could i know if test work correctly? I have just see if compile without erros?

It sends the same 14-bit control change messages as in your screenshots, but without Control Surface. It starts at position 0, and then gradually increases the volume to 100%.

If the DAW doesn't react to these messages, that means you have narrowed it down to one of two main things:

1. the DAW doesn't correctly receive the MIDI messages from the Teensy, or
2. the messages from your screenshot are incorrect, maybe the tablet app uses some kind of additional handshake using SysEx.

[MarcosGogo]

It sends the same 14-bit control change messages as in your screenshots, but without Control Surface. It starts at position 0, and then gradually increases the volume to 100%.

Perfect, now i understand 100% how this sketch works.

I used the midi monitor and the sketch is working perfectly, it's sending Control change gradually.

Unfortunately, when connecting the DAW, it didn't react to the command and didn't change any parameters. It really looks like daw is not being able to read this information correctly.

I have very shallow and abstract knowledge of midi implementation. Maybe what I come to say doesn't make any sense. But I've been watching some videos of BOME midi translator pro. And I noticed they have a tutorial on how to transform MIDI CC to Mackie Protocol to control the adobe premiere DAW which operates over MCU protocol. At first I figured it was just a midi address mapping, as from what I understand, the Mackie Protocol is just a mapping pattern. But during the video I noticed that it changes a variable parameter in the midi CC inside the BOME midi translator. It's a change from variable "pp" to "qq", after which the DAW can talk to the controller. Maybe this variable is just a control inside the bome translator programming, I have no idea. But I ended up raising this hypothesis only because I also noticed that within this code sketch you gave me, there is a "delta" parameter, which I believe may have something to do with some variable. I ask to understand if this command control "14bits CC" does not operate with some variable condition. And if so, if this variable is not responsible for my DAW not recognizing the control changes by MSB + LSB. Sorry if I'm saying something completely meaningless.

[tttapa]

There are no actual variables in the MIDI protocol itself, only in the software that sends or receives MIDI.

The MIDI messages themselves just consist of 3 numbers (at least control change messages do, other message types might have different lengths), usually written in hexadecimal:

0xB0 0x18 0xVV

The first byte 0xB0 is the status byte that indicates that it's a control change message on MIDI channel 1. The second byte is the controller number (18₁₆ = 24₁₀), and the third byte is the value, between 0x00 and 0x7F (0xVV is just a placeholder for the actual value, you always send a concrete value over MIDI).

If you are using 14-bit control change, you send 2 separate control change messages: one with the 7 most significant bits of the value, and one with the 7 least significant bits. The least significant bits are sent to controller number 0x18 + 0x20 = 0x38 = 56₁₀.

As you can see, control change messages are really simple, just these 3 numbers: status byte, controller number, and controller value. There are no variable conditions etc.

The delta variable in the code I posted is just a constant that determines by how much the value is increased at each tick.

[MarcosGogo]

The delta variable in the code I posted is just a constant that determines by how much the value is increased at each tick.

Ok Perfectly understand.

1. the DAW doesn't correctly receive the MIDI messages from the Teensy, or 2.the messages from your screenshot are incorrect, maybe the tablet app uses some kind of additional handshake using SysEx.

where do you think the problem is?

If option 1: In case it's a teensy communication problem. Do you think it might have something to do with TEENSY 2.0's midi over usb implementation, which might not be fully functional? In that case switching to a Teensy 3.x could it have a chance to work?

If option 2: Do you know any other WEB midi monitor that could give me some more accurate SysEx monitoring? The app also could be connected with DAW by midi over bluetooth. I could try to route its information, when it's being operated via bluetooth, to the tablet's USB output. And try to monitor this information by another more efficient app. But I still have no idea how to do this.

Thank you so much Peter for your attention and all the help so far.

[tttapa]

In case it's a teensy communication problem. Do you think it might have something to do with TEENSY 2.0's midi over usb implementation, which might not be fully functional? In that case switching to a Teensy 3.x could it have a chance to work?

Probably not. If I understand correctly, you were able to control the DAW using an encoder and V-Pot messages, right?

Do you know any other WEB midi monitor that could give me some more accurate SysEx monitoring?

https://www.roxxxtar.com/apps/miditool/ is quite handy.

[MarcosGogo]

Probably not. If I understand correctly, you were able to control the DAW using an encoder and V-Pot messages, right?

Yes encoder V-POT works correctly to control this parameter.

https://www.roxxxtar.com/apps/miditool/ is quite handy.

Thanks, i will try to monitor again with this midi monitor and see if i can get some more details.