Midi clock display jittery

Hey there, I am working on a project where the master controller is taking in midi (converted to serial) and displaying the Midi beat clock on the MVP touch panel
The display shows " BARS:BEATS:DIVISIONS" , every 6 times that the the panel receives the "$F8" message it advances the divisions by one unit. Everything seems to work fairly well except for when the tempo of my sequencer gets up around the 180 beats per minute tempo (72 x $F8 messages per second). The clock begins to get really jittery and advances in big chunks of time.
I am quite new and and need some guidance as to where the bottleneck is that is causing the jittering.
The "$F2" at the bottom of the code is to set the beginning position of the song position pointer and seems to work flawlessly.

Thanks.

DEFINE_CALL 'SEND MIDI COUNT'
{
SEND_COMMAND dvTP1,"'^TXT-50,0,',FORMAT('%02d',(1+(NMIDI_SPP/16))),':',FORMAT('%02d',(1+((NMIDI_SPP)%16)/4)),':',FORMAT('%02d',(1+(NMIDI_SPP %4)))"
}


DEFINE_EVENT

DATA_EVENT [dvMIDI]
{
STRING:
{
LOCAL_VAR CHAR JUNK[10]
MIDI_BUFFER = DATA.TEXT
WHILE (LENGTH_STRING(MIDI_BUFFER) > 0 ) //re-runs if there is data in the buffer after one round
{
NTEST3++ // for debug
CMIDI_STATUSBYTE = GET_BUFFER_CHAR(MIDI_BUFFER) // strips first byte of midi message
SWITCH(CMIDI_STATUSBYTE) // does things dependant on first byte of message
{
CASE $F8: // timing clock at 24 pulses per quarter note
{
Ntest1++ // for debug
nmidi_clock++
IF (NMIDI_clock >= 6 ) // every 6 ticks of timing clock
{
NMIDI_clock = 0
NMIDI_SPP++ // moves song position pointer up one division
CALL 'SEND MIDI COUNT' // sends data to TP
}

}

CASE $F2: // starting point of song position pointer
{
ntest2++ //debug
CMIDI_LSB = GET_BUFFER_CHAR(MIDI_BUFFER) // LSB of song position pointer
CMIDI_MSB = GET_BUFFER_CHAR(MIDI_BUFFER) // MSB of song position pointer
NMIDI_SPP =((TYPE_CAST(cMIDI_LSB))+(128*(TYPE_CAST(CMIDI_MSB))))
NMIDI_clock = 0
CALL 'SEND MIDI COUNT'
}
}
}

Comments

  • champchamp Junior Member Posts: 261
    You are flooding the touch panel input buffers, they are not designed to take 72 messages per second.
    Store the current midi clock in a variable and create a timeline that triggers no more than 10 times per second (5 times a second should be fine), on the timeline event send the current midi clock value.
    If timelines are too much effort then use a wait in mainline.
    I'd also create another variable to keep track of updates in the clock so you don't update the touch panel unnecessarily; and don't send updates when the panel is offline or it will get a surprising bucketload of junk when it comes online.
  • viningvining X Member Posts: 4,346
    You could also try modifying your gui to use multi-state bargraphs instead of a variable text box. If you create all the possible states for the clock and counters in your gui design then you can send the tp levels instead of text strings which should be easier for the master and tp to process which means more frequent level changes can be sent making for a smoother display.
  • craig@unifiedsystems.ca[email protected] Junior Member Posts: 8
    Hmm, the thing is that the message is only being sent to the TP every 6 pulses, so 12 or 13 times per second. I have tweaked the code before to test if it is the TP having problems but it seems to not have any problem handling well over 13 messages per second. Here is the line:

    IF (NMIDI_clock >= 6 ) // every 6 ticks of timing clock
    {
    NMIDI_clock = 0
    NMIDI_SPP++ // moves song position pointer up one division
    CALL 'SEND MIDI COUNT' // sends data to TP
    }
  • JasonSJasonS If I had known it was going to be that kind of party... Posts: 227
    I had the same issue with displaying MIDI Timecode on a touch panel. Updating the value for every frame (around 30 frames/sec), was way too much traffic, you couldn't read it that fast anyway. The way I handled it was only to update the display only when frames modulo 5 = 0. That reduced the update to 6 times per second.
  • craig@unifiedsystems.ca[email protected] Junior Member Posts: 8
    Tried putting the send_command to the TP in a timeline event. Same result.
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,141
    Hey! Audio Engineer geek moment!

    I have found it's best to create essentially a different frame rate for the touch panel. Sending the MIDi/SMPTE time clock at the roughly 30fps it spews out at is just to much traffic for the poor thing. If you write a routine to convert the time scale coming from themMIDI clock to downscale it to between 5-10 fps, you might find your TP Able to handle it. Just skip sending time data that comes in between TP frames. You could just do the math and divide by 3-6 to get there. Or you could make a timeline that grabs the current MIDI time at the 5-10 fps frame rate. I'd do the latter myself. The human eye won't see that much of a difference and you won't be making the TP drink from a fire hose.
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    champ wrote: »
    don't send updates when the panel is offline or it will get a surprising bucketload of junk when it comes online.
    That’s not true, is it? Once a TP drops off line all channels and levels go to 0. Any command along with all channel and level feedback won’t get sent or queued by the master if the destination device is offline. They just get ignored. Once the TP comes back online it’s up to the code to update the channels, levels, and variable text. That’s been my understanding.
  • craig@unifiedsystems.ca[email protected] Junior Member Posts: 8
    ericmedley wrote: »
    Hey! Audio Engineer geek moment!

    I have found it's best to create essentially a different frame rate for the touch panel. Sending the MIDi/SMPTE time clock at the roughly 30fps it spews out at is just to much traffic for the poor thing. If you write a routine to convert the time scale coming from themMIDI clock to downscale it to between 5-10 fps, you might find your TP Able to handle it. Just skip sending time data that comes in between TP frames. You could just do the math and divide by 3-6 to get there. Or you could make a timeline that grabs the current MIDI time at the 5-10 fps frame rate. I'd do the latter myself. The human eye won't see that much of a difference and you won't be making the TP drink from a fire hose.

    Midi timecode and Midi Beat Clock are two different things. The beat clock is tempo dependant while timecode is more of an absolute time. I can reduce the traffic from the controller to the TP as much as I want via timeline but it doesn't seem to help. Here is a breakdown of what should be happening.

    - Every six "$F8" received, NMIDI_SPP++
    - Six times per second, display "NMIDI_SPP" // just added this via timeline, didn't seem to help
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    Have you confirmed that the data you think you’re sending is the data you’re actually sending? As a suggestion I would:

    Change this:
    DEFINE_CALL 'SEND MIDI COUNT'
    {
    SEND_COMMAND dvTP1,"'^TXT-50,0,',FORMAT('%02d',(1+(NMIDI_SPP/16))),':',FORMAT('%02d',(1+((NMIDI_SPP)%16)/4)),':',FORMAT('%02d',(1+(NMIDI_SPP %4)))"
    }
    

    To this:
    DEFINE_CALL 'SEND MIDI COUNT'
    {
    SEND_COMMAND dvTP1,"'^TXT-50,0,',FORMAT('%02d',(1+(NMIDI_SPP/16))),':',FORMAT('%02d',(1+((NMIDI_SPP)%16)/4)),':',FORMAT('%02d',(1+(NMIDI_SPP %4)))"
    SEND_STRING 0,"'^TXT-50,0,',FORMAT('%02d',(1+(NMIDI_SPP/16))),':',FORMAT('%02d',(1+((NMIDI_SPP)%16)/4)),':',FORMAT('%02d',(1+(NMIDI_SPP %4)))"
    }
    

    Maybe there is a flaw in the math or in the data processing? It might be worth trying to rule that out at this point. Just a thought...
  • craig@unifiedsystems.ca[email protected] Junior Member Posts: 8
    Have tried sending just nMIDI_SPP to the panel without the formatting and it doesn't help. Im pretty sure I have eliminated the TP from the list of potential problems. I have also done tests where I eliminated MIDI the parsing from the equation and sent the data to the TP much faster than I am without a problem.
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    Have tried sending just nMIDI_SPP to the panel without the formatting and it doesn't help. Im pretty sure I have eliminated the TP from the list of potential problems. I have also done tests where I eliminated MIDI the parsing from the equation and sent the data to the TP much faster than I am without a problem.
    If that’s the case then it sounds like the jittery display is self inducted, no? That’s why I suggested the debug messages. Maybe you are seeing exactly when you are sending. Good luck...
  • craig@unifiedsystems.ca[email protected] Junior Member Posts: 8
    Joe Hebert wrote: »
    If that’s the case then it sounds like the jittery display is self inducted, no? That’s why I suggested the debug messages. Maybe you are seeing exactly when you are sending. Good luck...

    Im unsure what you mean by self inducted. I agree that I think I am seeing exactly what I'm sending and that the TP is accurately displaying the value of nMIDI_SPP (however I decide to format). I just can't figure out why that variable seems to change in big increments once the tempo gets fast enough. Again, I'm the rookie but I'm leaning towards one of 3 things
    1. code parsing/processing in-efficiencies
    2. serial to midi conversion problems (outside the scope of AMX on this one)
    3. hardware processing limitations (anyone with any input on this ?)
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    Self inducted should have read self induced. An extra t dropped in there.

    From what you’ve posted so far I can’t tell what is making the variable (nMIDI_SPP?) change in big increments. Hopefully someone else can.
  • champchamp Junior Member Posts: 261
    Joe Hebert wrote: »
    That’s not true, is it? Once a TP drops off line all channels and levels go to 0. Any command along with all channel and level feedback won’t get sent or queued by the master if the destination device is offline. They just get ignored. Once the TP comes back online it’s up to the code to update the channels, levels, and variable text. That’s been my understanding.
    You are most likely correct, I just code carefully when I am not sure what goes on in the background, and who knows what joy future firmware changes may introduce.
    Im unsure what you mean by self inducted. I agree that I think I am seeing exactly what I'm sending and that the TP is accurately displaying the value of nMIDI_SPP (however I decide to format). I just can't figure out why that variable seems to change in big increments once the tempo gets fast enough. Again, I'm the rookie but I'm leaning towards one of 3 things
    1. code parsing/processing in-efficiencies
    2. serial to midi conversion problems (outside the scope of AMX on this one)
    3. hardware processing limitations (anyone with any input on this ?)

    What others are suggesting is that maybe AMX is displaying exactly what it is being told and that the MIDI strings coming in have errors; so this could be the second possibility on your list, or maybe the problem is occurring before the MIDI to serial conversion.
    The only way to know if the problem is in the AMX is to look at the incoming strings in diagnostics.

    The next thing i suggest is some error correction, compare values before sending to the touch panel, if the value change is above a threshold then assume it is an error.
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    champ wrote: »
    I just code carefully when I am not sure what goes on in the background, and who knows what joy future firmware changes may introduce.
    Yup, always best to err on the side of caution.
  • JasonSJasonS If I had known it was going to be that kind of party... Posts: 227
    Just out of curiosity, what is the baud rate of the serial data you a receiving from the MIDI to serial converter?
  • craig@unifiedsystems.ca[email protected] Junior Member Posts: 8
    JasonS wrote: »
    Just out of curiosity, what is the baud rate of the serial data you a receiving from the MIDI to serial converter?

    Tried a 38.4k and 115k. Im starting to think that the serial/midi converter might be buffering, I've got a couple optocouplers and max232 chips coming and I'm going to make my own converter. I understand that AMX master controllers can do 31.25k so only voltage conversion is required, not baud rate.
  • JasonSJasonS If I had known it was going to be that kind of party... Posts: 227
    Cool. I am interested to hear how it turns out.
  • Jim JohnsonJim Johnson Junior Member Posts: 24
    Full disclosure, I know nothing about Midi, However I sounds like a you may be over-running the CPU in the AMX. have you done a "CPU Usage" while running the program? I try to keep simple programs (boardrooms etc) to below 50%, when you get to 90% some very strange things happen. I have had random arrays just clear out while everything else seems fine. You may have to refine your program to conserve CPU.
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,141
    Full disclosure, I know nothing about Midi, However I sounds like a you may be over-running the CPU in the AMX. have you done a "CPU Usage" while running the program? I try to keep simple programs (boardrooms etc) to below 50%, when you get to 90% some very strange things happen. I have had random arrays just clear out while everything else seems fine. You may have to refine your program to conserve CPU.

    MIDI is one of the most chatty protocols I've ever done. It depends on what's going in. I did a high-end teleconferencing system with a broadcast quality video desk (Grass Valkey) and a digital mixing console. (Neve ) the midi was a fire hose.
Sign In or Register to comment.