if I have a midi automation like this
and now am dragging the last track column one position to the left
and then decrease the number of track columns
the fx commands will not be reconnected together to valid midi events again (which will happen if I drag the column back to last position instead) and the fx stays/turns into ugly random like device on/off automation instead (** the midi automation actually will work again, but also the device automation will stay, see testcase below).
Also I would like to highly suggest to you to totally decouple on/off device automation from midi automation, e.g. using unique fx command instead of double-use Mx-commands and providing a automatic song conversion then. Or maybe it would be even even better, if you were providing graphical on/off automation.
Besides the above reason, there are also the following reasons to change the double-usage of Mx:
In the above scenario, if I accidentally change the song position and the song option “automation following” is enabled, and the song position now passes those values, a lot of on/off automation and preset hopping will appear, which also will not be saved in undo history. So it will end up irreparable
There are other scenarios AFAIK which I did forget in detail, when a midi automation will accidentally turn into on/off automation. I think it was quantization in adv. tools and also as a tool
You can never say for sure, if a device will be accidentally automated, because there is no automation indicator at all. So Russian roulette style. Also there is no indicator for preset switch automation
Here is a testcase song. Please repeat the above step 1, watch device no.1 “stereo expander” and device no.3 “eq5”. Make sure that you scroll over those values and have “automation following” enabled. Then reduce the column count. The midi automation is listenable again, but also device no.1 still has this automation there.
bug onoff automation.xrns (9.8 KB)