I spent the last couple of weeks (in spare time) going through the decompiled code and refactoring so I could understand what the code is actually doing/trying to do. You'll likely be glad to know I saw the "crazy logging" error (fill up the log over 25 MB in less than a minute) too... I hit the "crazy logging" after I fixed that same other error by adding that same import.I kind of understand what the code is doing now, but "button presses" on the device still do not seem to be reaching the C4-script code. Communication from Live to the device seems to be working normally, and knob turns (CC messages) are reaching Live from the C4, but button presses (Note ON messages) are not. There is a huge difference between "hand written" code and "decompiled" code, but I think I've been fairly successful refactoring the decompiler's code back to a more "hand written" form. (For example, there are at least four "constants" defined that represent the number 8. How is a decompiler going to know which constant "label" goes with which 8 in the code? It can't. But a human, reading carefully and understanding sometimes multiple contexts, can determine whether a certain instance of the number 8 means, for example, the number of encoders in a row, the first encoder on the second row, the button on the first encoder on the second row, the Shift button, the number of parameters in a bank, or something else, like a snowman.)
Next I plan to get some debugging "log statements" into the code that will appear in Live's log so I can hopefully make a little progress figuring out why the stuff that isn't working yet isn't working, and fix it. Once I have the script "repaired" and working in Live 10, I'll give you copies of the files before I start making "my own" changes. I don't know how possible my goal is, but I want to try making a script that kind of clones the "run" mode in the original C4 Commander software, except, of course, that the script works in and with Live. For example, I would like the C4 (remote script) to be able to use/reference the .c4i (instrument definition) and .c4l (Device Layout) xml files that C4 Commander uses/references/creates. It would be sweet if I can create layouts in Commander that the C4 (remote script) can understand (along with the related instrument definitions) and pass to (or through) Live as midi messages or whatever.
BTW - This error: "upper_string1 += self.__generate_6_char_string(unicode(self.__display_parameters[t][1])) list index out of range" means the list represented by self.__display_parameters[t] does not contain anything (text) at index 1. When the script is initializing properly, there will be text at that index 1, but before I knew that fact, I added code to ensure the unicode() method always gets text (that it doesn't matter how many indexes are "in range" for self.__display_parameters[t]).
Like this: (except with proper indentation)
text_for_display = self.__display_parameters[t]
u_alt_text = 'zzz'
l_alt_text = 'xxx'
if len(text_for_display) > 1:
u_alt_text = text_for_display[1]
l_alt_text = text_for_display[0]
elif len(text_for_display) > 0:
l_alt_text = text_for_display[0]
You can add this code inside the two for loops (above the if/elif conditionals, above line 621 in the top loop, below 621 of course in the other loop) in that on_update_display_timer() method and it should stop the Live log from filling up with those errors. [ you also need to replace self.__generate_6_char_string(unicode(self.__display_parameters[t][1])) with self.__generate_6_char_string(unicode(u_alt_text)) or l_alt_text as appropriate, starting at line 621 ] The reason the log fills up so fast repeating that error message is because on_update_display_timer() is a bad place for an error because on_update_display_timer() is "called" so often, every time Live "refreshes the C4 display" which could easily be more than a dozen times per second.
