Pro Tools Rec Light

Yes they are all wrong. First off you need a double equal sign in them to compare anything. But the big mistake is that you first fill your Expression control variable with a value you device from the MIDI messages and then you test it with an if statement to see if it is the number you are looking for.
When you find that it is that number then you do something about it like controlling your LED. The if statement when true will execute the statement following or the block following defined in curly braces.

You need to post all the code you have not just a part as I suspect more of it is totally wrong like this.

Grumpy_Mike:
You need to post all the code you have not just a part as I suspect more of it is totally wrong like this.

That is all code I've got. I just want to make this rec light to shine and nothing more. :slight_smile:

Grumpy_Mike:
First off you need a double equal sign in them to compare anything. But the big mistake is that you first fill your Expression control variable with a value you device from the MIDI messages and then you test it with an if statement to see if it is the number you are looking for.
When you find that it is that number then you do something about it like controlling your LED. The if statement when true will execute the statement following or the block following defined in curly braces.

I changed the code a bit and again I'm not sure I did it correctly:

#include <MIDI.h>

int ExpressionContr1 = 1;
int ExpressionContr2 = (0xC, 0x2C) ;
int ExpressionContr3 = (0xE ,0x45) ;
int ExpressionContr4 = (0xE,0x5);
MIDI_CREATE_DEFAULT_INSTANCE();

     void setup() 
{
pinMode(13,OUTPUT);
MIDI.begin(); 
MIDI.setHandleControlChange(MyCC);

}
     void loop() {
 
MIDI.read();
}

void MyCC( byte channel, byte controller, byte value ) {
 

if (ExpressionContr1==(channel==1<<7)|(channel==1 & 15 ))
if (ExpressionContr2==(controller==0xC <<7) | (controller==0x2C & 0x7F ))
if (ExpressionContr3==(value ==0xE <<7) | (value ==0x45 & 0x7F ))

digitalWrite(13,HIGH);

if (ExpressionContr1==(channel==1<<7)|(channel==1 & 15 ))
if (ExpressionContr2==(controller==0xC <<7) | (controller==0x2C & 0x7F ))
if (ExpressionContr4==(value ==0xE <<7) | (value ==0x5 ))
digitalWrite(13,LOW);

}

But something is still wrong.
Tried different ways to write the variables:

int ExpressionContr2 = 0xC| 0x2C ;
int ExpressionContr2 = (0xC)| (0x2C) ;

Alt/opt still disturbs.

I experimented with the code: when I change the placements of notes ("reversed sequence") alt/opt is out of the game, but now the "play" button turns the light on(for a short time). Argh!

OK that code it totally screwed in many many ways.
This is something on the right track. I have not tested it but it does compile. See if you can understand what it is doing. The "magic numbers" might not be right.

#include <MIDI.h>
// I assume these are the right magic numbers
int ExpressionContr1 = 1;
int ExpressionContr2 = (0xC << 7) | 0x2C ;
int ExpressionContr3 = (0xE<< 7) | 0x45 ;
int ExpressionContr4 = (0xE<<7) | 0x5;
int controlRecieved;
byte ccMessage12Value;
byte ccMessage44Value;
boolean ledState;

MIDI_CREATE_DEFAULT_INSTANCE();

void setup(){
pinMode(13,OUTPUT);
MIDI.begin();
MIDI.setHandleControlChange(MyCC);
}

void loop() {
MIDI.read();
}

void MyCC( byte channel, byte controller, byte value ) {
 // build up your full message
  if(controller == 44){
  ccMessage44Value = value;
  ccMessage12Value = 0; // blank MSB of message to stop rapid on / off of LEDs
 }

 if(controller == 12){
  ccMessage12Value = value;

// now put them together into one variable
controlRecieved = (ccMessage12Value << 7) | ( ccMessage44Value & 0x7F);
// now see if you have anything of intrest
// here you seem to test the same thing to turn it on or off so you need a variable to hold the state you last put the LED
if( (ledState == false) && (controlRecieved == ExpressionContr1 || controlRecieved == ExpressionContr2 ||controlRecieved == ExpressionContr3) ){
      digitalWrite(13,HIGH);
      ledState = true;
    } else {
if( (ledState == true) && (controlRecieved == ExpressionContr1 || controlRecieved == ExpressionContr2 ||controlRecieved == ExpressionContr4) ){
      digitalWrite(13,LOW);
      ledState = false;
     }
    }
  }
}

Please come back with questions about it.

If I could I would hug you!
Thank you million times for your patience and knowledge.
For these three days I've learned much more than for the last 6 months.
It works! :slight_smile:

Looking at the code it seems easy and everything is clear now. But I understand that it would take me a year or two (or may be never) to write it!

Thank you!

If I'm right this code will work with any DAW. Will check it tomorrow with Cubase and will post here. ))

I have just edited the code in reply #12. I just realised that when receiving the LSB in CC 44 it would use the last version of what was in the MSB from CC 12. This could result in a rapid on / off of the LED due to a false message being generated. Therefore I wiped out the old number in ccMessage12Value when ever CC 44 arrived.

There may well be other wrinkles like that, as I said I have no hardware to try this on.

If I'm right this code will work with any DAW.

Yes if it sends the same numbers.

Grumpy_Mike:
I have just edited the code in reply #12.

There is a problem with new edition since the "ARM TRACK" button sends 12 CC message with value 0. So when the tack is armed everything is messed up )).

Sorry I am not understanding you. What do you mean by 12 CC messages?
Is this
A CC message for controller 12? Or
Twelve messages of the CC type?

I think it is time to specify each group of messages, what you get and what you want to do when you get them.

I know you did this in the first post but it looks like things have changed.

Grumpy_Mike:
A CC message for controller 12?

Yes it's a CC message for controller 12 with value 0.
Sorry! Sometimes my English and the knowledge of programming makes me unclear))

Grumpy_Mike:
I think it is time to specify each group of messages, what you get and what you want to do when you get them.

Thing are the same!! Since ProTools uses HUI protocol to communicate with control surfaces it will take long enough to spy down all its messages. As I was interested in Rec button I "spied" on HUI with MIDI Monitor. I've just found the REC "pattern". As for other messages its unpredictable how many of them in HUI. Though it could be interesting to do that.

Still not sure about the problem but try changing

ccMessage12Value = 0;

To

ccMessage12Value = -1;

-1 didn't helped. The LED sometimes even doesn't respond. Sometimes it responds but never goes off.

Just in case I'll write about the messages concerning recording.
Before rec process I have to "arm" the track (to prepare it for recording).
When I press "arm track" HUI sends a lot of messages (since the arm button blinks they are on/off commands and I suspect the info about the track armed). First 10 are
(1,12,0)
(1,44,7)
(1,12,14)
(1,45,5)
(1,12,15)
(1,44,2)
(1,12,13)
(1,44,2)
(1,12,12)
(1,44,70)

When I press rec button HUI sends 10 CC messages. They are:
(1,12,14)
(1,45,5)
(1,12,15)
(1,44,2)
(1,12,13)
(1,44,2)
(1,12,14)
(1,45,5)
(1,12,14)
(1,44,69) My guess was these messages are responsible for REC LED

the button starts to blink and HUI sends:

(1,12,14)
(1,45,5) (here it is possible to see stop and rec together in on place i.e. on/off/on/off)
(1,12,14)
(1,44,69) ( I can refuse rec and turn it off by pressing rec button again - behavior like I press stop button)

and so on until I press play button. From this point ProTools starts to record things. The LED is continuously on. It's almost impossible to track down "PLAY" notes (a lot of them) + sysex notes (info about cursor position and so on) but the most common command is:
(1,44,68) - I think it is responsible for "PLAY LED"

I press stop and HUI sends:
(1,12,14)
(1,45,5)
(1,12,15)
(1,44,2)
(1,12,13)
(1,44,2)

May be that's unnecessary info, but just in case)))

OK there seems to be a lot going on here than first we thought. I looked at some proTools information and came up with the attached PDF.
In appendix A there is a list of what messages are sent for the LEDs and it seems to suggest that it is a SysEx message. It is the CC messages that seem to be concerned with the fader and switch data. This does not tie up with what you are reporting. Are we balking up the wrong tree, or does the attached document not describe what, the version of Pro Tools you have, actually sends.

MIDI_Controllers_Guide50.pdf (975 KB)

Yes, I saw these docs and also I read the results of "reversed engineering" . I don't know why but yes , what I see on my MIDI Monitor is different from the info in there. May be that's because of ProTools v5 (release1999)and now I've got v.12. (but why Cubase when using HUI protocol sends almost the data? - By the way the code works also in Cubase)
May be the reason is in using MIDI translators (quoting: "you can a use a third-party controller (such as the JL Coo- per FaderMasterTM) and program its con- trols to function like a JL Cooper CS-10." ) Who knows. May be (and that should be #1) I missed something.
There could be tons of reasons.
But the first version of your precious code works! And all the data used is the data from MIDI Monitor. (Sorry for the bold:))

When I press Record no Sysex info is transmitted (on all of the channels). Sysex appears only if I press Play button. Info about the other buttons is also sent via CC messages.

I decided to get rid of midi shield and changed the firmware. Now it is Hiduino. The program still works. :slight_smile:

Hello! Small update:
After couple weeks of testing during the real recording sessions I found a small bug. During recording when I try to choose a track (click on any track, armed or not) the LED shuts down. Fixed it!!! removing any info concerning channel byte. Now it works as should (sorry for the quality).

Don't understand why channel byte was an obstacle but it was. I'm going to check the idea with adding:

ccMessage12Value = -1; // blank MSB of message to stop rapid on / off of LEDs

May be this time (without channel info ) it will work.

Thank you!

Fixed it!!! removing any info concerning channel byte. Now it works as should

Well done. :slight_smile:

Thanks for the update.

Hello!
Another small update:

Mixing sessions brought a new bug: suddenly it turned out that "Scrubber Tool" when used sends tones of CC messages including the ones concerning record. The LED "rapidly turns on/off"... So, I was forced to deal with

 ccMessage12Value = 0; // blank MSB of message to stop rapid on / off of LEDs

and I found what was wrong with it!
I realised what it was for)) If it is correct I'd call it like: "MIDI debouncing". :slight_smile:
Dear Grumpy_Mike, your are GREAT!
All I had to to do is to change it to:

ccMessage44Value = 0;

since the message "ccMessage12Value" arrives first.
And voila: it works even better! I think from now I'm protected from new "surprises".

Thank you! :slight_smile:

and I found what was wrong with it!

Fantastic.
Mrs Grumpy says "that was the result you were aiming for but rarely get". To be able to fix your own stuff is good. :slight_smile:

Hi, after a week of fooling around with my first project...
Here is my code:

#include <MIDI.h>

//Flash arduino 8u2 or 16u2 chip with HIDUINO_MIDI.hex
//Set ProTools or other DAW to use MIDI controller / HUI protocol / arduino_midi (default hiduino name)
//The two sets of messages that we are looking for are:
// RECORD ON
// 1) channel 1,  controller 12, value 14 
// 2) channel 1,  controller 44, value 69
// RECORD OFF
// 1) channel 1,  controller 12, value 14 
// 2) channel 1,  controller 44, value 5

int firstMsg=0;  // set int for the first part of the two messages

MIDI_CREATE_DEFAULT_INSTANCE(); 

void setup(){
//Use LED for reference
pinMode(13,OUTPUT); 
// Listen for MIDI on channel 1 only
MIDI.begin(1); 
//Listen for incoming ControlChange MIDI messages and pass bytes to function if received
MIDI.setHandleControlChange(CCSequence); 
}

void loop() {
MIDI.read(); // Read all incoming MIDI data
}

//Function that will receive the CC MIDI Bytes
void CCSequence(byte channel, byte controller, byte value  ) { 
  //Check if CC message is equal to the first part of our two sequences:
  //1) channel 1,  controller 12, value 14 
  if((channel==1)&&(controller=12)&&(value==14))
    {
      //Mark first part of the sequence as received
      firstMsg=1; 
    }
    
  //If first part is received look for the second part of our two sequences
  if(firstMsg==1)
      {
        //Check if CC message is the second part of RECORD ON
        //2) channel 1,  controller 44, value 69
        if((channel==1)&&(controller=44)&&(value==69))
          {
            //Turn LED ON
            digitalWrite(13, HIGH);
            //Reset Marker. We start waiting for the first part of the sequence again
            firstMsg=0;
          } 
        //Check if CC message is the second part of RECORD OFF
        //2) channel 1,  controller 44, value 5
        if((channel==1)&&(controller=44)&&(value==5))
          {
             //Turn LED OFF
             digitalWrite(13, LOW);
             //Reset Marker. We start waiting for the first part of the sequence again
             firstMsg=0;
          }
      }
}

Hi! I'm trying to do something very similar but I'm using a Teensy 3.2

I copied your code but it keeps giving me this error message:

Arduino: 1.6.11 (Mac OS X), TD: 1.30, Board: "Teensy 3.2 / 3.1, MIDI, 96 MHz optimize speed (overclock), US English"

hui_controller:15: error: expected constructor, destructor, or type conversion before ';' token
MIDI_CREATE_DEFAULT_INSTANCE();
^
Using library MIDI in folder: /Applications/Arduino.app/Contents/Java/hardware/teensy/avr/libraries/MIDI (legacy)
expected constructor, destructor, or type conversion before ';' token

I was just wondering if there is a way to adapt this for the Teensy?