I didnt know how to properly describe this in the title... I am having difficulties to find a bug that caused my LCD displays to go blank.
to describe the problem in short: I have two LCD displays that I need to use to visualise NI traktor audio effects. This is part of a MIDI controller (working as mixer for Traktor).
Now, in the code I need at times to send a midi message to traktor, which in turn send back midi messages with the current states of parameters (this is to update led mainly but also other staff).
I use this in the code to do that:
when receiving this message, traktor send a global monitor state message back.
this cause the lcd to go blank. to display the information again I simply press a button that normally I use to swaps the effect racks (which basically updates the display and brings back the information on the display) . funny enough if I put the same function triggered by that button after the MIDI_STATE_REFRESH, that doesn't work. (?)
I have been checking the code numerous time but can't find the problem. I will upload the code in case anyone is able to give any advice, at least on where to start...
the file is very long but clearly the only relevant bits are that are those one happening after MIDI_STATE_REFRESH.
I wander if the amont of midi data (it looks like traktor sends back180 midi messages when I ask for the refresh) could be causing this ...
in the file there is a library that I created myself, i can post that if needed.
this is the library just in case: INHK_Pot3.cpp (803 Bytes) INHK_Pot3.h (1.1 KB)
That's way too long for anyone to go through and debug for you, especially without access to the hardware and DAW. You'll have narrow down the issue first.
Of Course! I wouldn't expect that. I just posted it as in previous posts people asked me to do that, to glance it I suppose. I think the issue is either that 180 midi message all in one go are causing problems or that some of these messages are "invalid" and are cousing the LCD to go blank. . I am still worknig on it trying to figure out.... may post something more specific as soon as I narrow down the problem but at the moment I am a bit lost...one thing is for sure, it is the midi messages that are causing it as I havce reproduced the same issue just by triggering the traktor "send monitor state" with a midi keyboard... as soon as I did that the lcd display went blank.
this is the midi message that are coming through after each MIDI_STATE_REFRESH send monitor state.txt (4.8 KB)
it last about one second... (it doesnt cause problems for the trellis, also wired in I2C)
so far I have been able to resolve the problem by creating a function that updates the display only after 1100ms have elapsde after the monitor midi state is triggered.
#define REFRESH_DELAY 1100 // delay between traktor send monitor state and LCD display refresh
unsigned long lastRefreshTime = 0; // To store the last time the action was performed
bool allowLCDRefresh = false; // Flag to indicate if the delayed function has started
// this is used in the code when I need to refresh ...
void refreshTraktorMidiState(){
Serial.println(F("refreshing Traktor midi state"));
usbMIDI.sendControlChange(127, 127, 1);
lastRefreshTime = millis(); // Initialize the previousMillis with the current time
allowLCDRefresh = true; // Set the flag to indicate the first function has run
}
//this one goes into the loop:
void refreshLCD() { // this function adjust LCD after traktor send monitor state
if (allowLCDRefresh) { // Flag indicates that refresh is needed/allowed
unsigned long currentMillis = millis(); // Get the current time
if (currentMillis - lastRefreshTime > REFRESH_DELAY) { // Check if the specified delay duration has passedbetween traktor send monitor state and LCD display refresh
fxDisplayUpdate(0);
fxDisplayUpdate(1);
allowLCDRefresh = false; // Reset the flag to avoid repeated calls
}
}
}
in this way I am able to bring back the info in the display but the solution is less than ideal as anything below 1100 will not work properly, ie at 1000ms only the first display updates.
It turned out that there was no bug in my code that could cause this issue.
I am now convinced that the cause this glitch is the sheer amount of midi data sent back from taktor to the controller. I have a large number of midi assignments and when a message is sent to traktor to update them, it sends them all back in and it is simply too many messages for them to be handled efficiently by the midi.read() function . I hope this may be useful information for whoever encounter this issue with traktor....
I remember your code; plenty of INO files. Clever to post the .ino.cpp instead of the individual files; but the arduino builder might have dropped a stitch and created an incorrect file. Or does so when compiling the code from the opening post; I did not manage to compile your mixer.ino from the opening post which might be caused by this while I did manage to compile your original from Odd compile error: "No such file or directory" cause: #include #define SOLVED.
These are the first few errors
C:\Users\bugge\OneDrive\Documents\Arduino\1_forum.arduino.cc\1310338\mixer\mixer.ino: In function 'void (* press1(keyEvent))(keyEvent)':
C:\Users\bugge\OneDrive\Documents\Arduino\1_forum.arduino.cc\1310338\mixer\mixer.ino:135:5: error: 'usbMIDI' was not declared in this scope
usbMIDI.sendNoteOn(evt.bit.NUM + MIDI_MSG_OFFSET + offset_Trellis1, 127, TRELLIS1_MIDI_CH);
^~~~~~~
C:\Users\bugge\OneDrive\Documents\Arduino\1_forum.arduino.cc\1310338\mixer\mixer.ino:143:5: error: 'usbMIDI' was not declared in this scope
usbMIDI.sendNoteOff(evt.bit.NUM + MIDI_MSG_OFFSET + offset_Trellis1, 127, TRELLIS1_MIDI_CH);
^~~~~~~
I understand why you added the zip in your previous topic. The only problem with ZIPs is that people don't trust them if they come from an unknown source.
thanks @sterretje !
I am in the process of tidying up the project, which to be honest has grown quite a lot and a bit difficult to manage. While going through it it looks like there are functions that I could have built in a more efficient or easy to read manner. I On the whole it's working, it's just difficult to add things to it without making it more messy than it is already....
I did not manage to compile your mixer.ino from the opening post which
The file was compiling for me nut I will update the file with my latest version, which compiles in the arduino IDE.
I am pretty confident that the problem I encountered is due to the handling of the MIDI data, as it only occurs when I trigger a "monitor midi state" message from traktor. I worked around the problem by creating a delayed refresher function that updates the LCD display again after "monitor midi state", just not immediately but 1 second later. It works ok (I suppose I have to be happy with it). The ideal solution would have been to have a way to customised feedback from traktor, but this does not seem to be possible for the way traktor works. So when I ask traktor so send me the "monitor midi state" it sends the whole lot....
@sterretje I am glad to say that I have found what the issue was. I have to say it was to do with my code. I decide to start filtering all the midi messages that were coming through and noticed that some specific messages were causing the problem, not the amount of them. I then realised that in the way I had written my code (and this was intentional) every time I was moving a control the LCD would update the display the relative rack. So when the midi monitor state messages were coming through they would mess up my lcd, as the messages were making it flip from one rack to the other quickly. However, I didn't actually need this functionality as I prefer to manually change the rack displayed, so I removed it and now it appears to work as expected.
So it wasn't a bug, but more of a planning mistake ... if I change one parameter at the time, it make sense to have an automatic switcher to the various effect rakcs, but not when I am receving midi mgs for tens of rack controls at the same time....
I must say I had to strip my code back to the basic everything, and I am glad I did as there was a lot of useless staff in it.
some times we have to take a step back in order to go forward ...
