search

markusschloesser / MackieC4_P3

A Mackie C4 Midi Remote Script for Ableton 11
20 stars 2 forks source link

currently remaining errors in logfile for master release (8th May 2021) #78

Closed markusschloesser closed 1 year ago

markusschloesser commented 3 years ago 
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Suite\Resources\MIDI Remote Scripts\MackieC4\MackieC4.py", line 388, in track_change
RemoteScriptError: assert self.track_count == len(tracks)
RemoteScriptError: AssertionError

RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Suite\Resources\MIDI Remote Scripts\MackieC4\MackieC4.py", line 937, in <lambda>
RemoteScriptError: cb = lambda: self.device_changestate(track, tid, type)
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Suite\Resources\MIDI Remote Scripts\MackieC4\MackieC4.py", line 945, in device_changestate
RemoteScriptError: self.__encoder_controller.device_added_deleted_or_changed(track, tid, type)
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Suite\Resources\MIDI Remote Scripts\MackieC4\EncoderController.py", line 269, in device_added_deleted_or_changed
RemoteScriptError: selected_device_idx)
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Suite\Resources\MIDI Remote Scripts\MackieC4\EncoderAssignmentHistory.py", line 287, in device_added_deleted_or_changed
RemoteScriptError: assert no_devices_on_track # == True
RemoteScriptError: AssertionError

both of them not that often. Don't remember how to replicate (was in session)

BilldarBagdar commented 3 years ago

If they don't seem to cause any other problems, we can comment out those assertions. I mean, I added them because we were troubleshooting, and I think that's a great way to (temporarily?) "document" your understanding of the code, and verify the understanding at runtime. "At this execution point in the code I expect there are never any devices on the selected track", for example.

Because there are cases where we see these assertions logged because they "failed", it means, my understanding of the code at that point is/was less than complete. However, because you didn't notice any issues "in session" after the errors were logged, it means my misunderstanding isn't/wasn't critical. I mean if in the case when there is at least one device on the track when the execution pointer passes through that block of code and the assertion error is logged, and then "nothing bad" happens, like "log vomit", then the mere fact that there were devices present when we (I) didn't expect it doesn't really matter. No harm. No foul. On the other hand, if you were investigating some error you encountered a bit later "in session" and scrolled up to find this assertion error logged, then the "misunderstanding" would be more important. The assertion error would indicate the presence of at least one device on the track when none was expected in that block of code likely lead directly to the other error (and thus needs further investigation into why there was a device on the track at that point when it wasn't expected).

edit