Go Down

Topic: Pro Tools Rec Light (Read 1 time) previous topic - next topic

Grumpy_Mike

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.

Quote
If I'm right this code will work with any DAW.
Yes if it sends the same numbers.

gabermusic

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 )).

Grumpy_Mike

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.

gabermusic

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))

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.



Grumpy_Mike

Still not sure about the problem but try changing
Code: [Select]
ccMessage12Value = 0;
To
Code: [Select]
ccMessage12Value = -1;

gabermusic

#20
Oct 17, 2016, 11:54 am Last Edit: Oct 17, 2016, 11:59 am by gabermusic
-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)))


Grumpy_Mike

#21
Oct 17, 2016, 03:45 pm Last Edit: Oct 17, 2016, 03:45 pm by Grumpy_Mike
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.

gabermusic

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.   

gabermusic

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

gabermusic

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:
Code: [Select]
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!

Grumpy_Mike

Quote
Fixed it!!! removing any info concerning channel byte. Now it works as should
Well done.  :)

Thanks for the update.

gabermusic

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
Code: [Select]
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". :)
Dear Grumpy_Mike, your are GREAT!
All I had to to do is to change it to:
Code: [Select]
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! :)

Grumpy_Mike

Quote
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.  :)

FLIKI

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

Code: [Select]


#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;
          }
      }
}

Go Up