I have a DA micro.clock that is configured to have 4 presets. The micro clock is set up to send a PC message corresponding to the preset number when I press it’s button, and when I press and hold the button it goes back. Although the way it does this isn’t ideal, it increments by one then decrements by two, sending PCs along the way. Here’s a midi monitor capture to illustrate:
This illustrates starting from 1 and wrapping back around to 1. This works great, and my MC8 responds appropriately by moving from bank 1 through 4 and back around to 1 as expected. Things get interesting in the “previous” scenario. First, let’s look at what the clock does, starting at preset three:
First we send PC4, then three, then two. Oddly, the MC8 ends on bank 3. Here’s the corresponding sysex messages that the MC8 is processing during that same sequence:
We can see that on the 9th hex value we follow a sequence of 04, 03, 03. While I haven’t attempted to reverse engineer this message, I’m fairly certain that the 9th hex value corresponds to the bank number the device is switching to. I can prove this by simply paging through banks and watching that number increment or decrement. In this case, it looks like the device goes to PC4, then PC3, then PC3 again. This tracks with how the device reacts when I do a “preset decrement” on the micro.clock. The MC8 is indeed at bank 3.
Is there any other things I can do to troubleshoot this issue? It appears the micro.clock is doing what it should, but the MC8 seems to be reacting strangely?
