BilldarBagdar
commented
3 years ago This issue might be the result of a different error. When a track is deleted the "track_deleted" method will be called. The "track_removed" method takes the index of the removed track as input and updates the "list db" lists by removing the index and resorting the list. We should look carefully at that method to make sure it handles "all cases" correctly. It seems to handle "interior" Track deletions ok, but not the "last track" on the right. Why would that be? "Off by one" is a very common programming problem that could be in effect here. Especially because the track_deleted method doesn't use the track_index input parameter value that is passed in. The body of the method is relying on the accuracy of existing data
for t in range(self.t_current + 1, self.t_count, 1):
for d in range(self.t_d_count[t]):
self.t_d_p_count[(t - 1)][d] = self.t_d_p_count[t][d]
self.t_d_p_bank_count[(t - 1)][d] = self.t_d_p_bank_count[t][d]
self.t_d_p_bank_current[(t - 1)][d] = self.t_d_p_bank_current[t][d]
self.t_d_count[t - 1] = self.t_d_count[t]
self.t_d_current[t - 1] = self.t_d_current[t]
self.t_d_bank_count[t - 1] = self.t_d_bank_count[t]
self.t_d_bank_current[t - 1] = self.t_d_bank_current[t]This nested loop is best explained with small values I think. If you have 4 tracks correctly tracked in this "list db", and one is deleted, then this nested for loop just does a "left shift" of the data. Say the 2nd track is deleted. Before Track 2 can be deleted it will be selected, so the "current track" is 2 at the time "track deleted" is called. What the loops above do is assume self.t_current already points to the deleted track (which it does) and then starting from "t_current + 1" (the next track"), copies the data down one index. So if the lists contained data about tracks 1, 2, 3, 4 before track 2 was deleted and track_deleted was called, the lists contain data about tracks 1, (2=3-1), (3=4-1) after track_deleted returned.
Now, imagine that the only track is deleted (or the last track), which track is at index t_current +1?
I suspect you don't see the error reported until "rebuild_midi_map()" because the code gets into the wrong branch, the else branch here
if len(self.selected_track.devices) == 0:
self.__chosen_plugin = None
self.__reorder_parameters()
else:
selected_device = self.selected_track.devices[self.t_d_current[self.t_current]]
self.__chosen_plugin = selected_device
self.__reorder_parameters()
self.__reassign_encoder_parameters()
self.request_rebuild_midi_map()
returnI mean, if "_chosen_plugin is None" as in self.__chosen_plugin = None I don't think you would see the boost midi mapping error. But I could still be wrong.
markusschloesser
When the last device of a track is deleted, the script goes crazy with an index error and I THINK the main problem is this:
Unfortunately I do not know how to fix this currently (even though I probably spent 6 hrs looking into this already) and I think it's due to LOM changes (Live 8 => Live11)
Update: adding the "sensitivity" to the midi map signature thing improves things, see commit notes. Careful! If you delete the last device and then select the device again on the C4, the log file will fill up VERY quickly.