bitSync wrote:
OK, so the MCP version of the fader position you're transmitting transmits values in the range of 0x0000 to 0x03FF (actual numerical values, not MCP-encoded MIDI Data bytes) but instead of 1024 possible values, there are 256 possible values in increments of 4? I think the 0x7 in the MCP 0x7F lower order byte (MIDI Data1) is supposed to set the lowest 3 bits of the position value and the 0xF of the 0x7F is irrelevant? I guess d8bridge has to do something similar to get a 10 bit MCP fader value out of a 8 bit native d8b fader value. I suppose it is up to the DAW host software (in Sonar's case, the mackiecontrol.dll) to manage the non-continuity in fader position values (the jumps by 4 in adjacent fader positions)?
yes it increments the values by 4, and I suppose the lowest nibble from the low byte of MCP value is irrelevant, maybe I could emulate the increments by 1, sending four MIDI messages for each d8b increment but maybe I would need to add a small delay or something,
bitSync wrote:Thank you very much for any clarification you can provide here. I've been wondering for quite a while if the D8Bridge fader implementation was equivalent to the MCU fader implementation. Although I've never seen the MCU serial data, Mackie does advertise a 10 bit fader resolution on the MCU. I'm wondering if it's 1024 discrete steps in increments of 1 or if its 256 discrete steps in increments of 4? I'm also wondering if anybody can hear that difference or if the DAW software effectively averages those increments out? Thanks!
too bad I just sold my MCU a week ago, now I can't see the data it sends, but I guess it was real 10 bit , I think maybe it wouldn't make a noticeable difference, and also, some DAWs have functions to "smooth" the faders movements
