I consider myself a pretty advanced BMT Pro user, but no one is perfect and there is always something to be missed.
I read here and there that the MCU implementation of DaVinci Resolve leaves quite a few things to be desired, but I am not sure if it could be that ridiculous.
I implemented the faders, mute and solo buttons as well as bank switching etc without a hiccup.
But when it comes to the VPots I am a bit speechless, I am using of course relative encoders as specified, and I am using the minimal tick size of 1.
So, e.g. I am sending
B0 10 01 and B0 10 41 for my pan on chanel 1. This moves the pan in DVR not by 1 up and down but by +/-8, +/-7, +/-8… I mean this is a complete ridiulous resolution given the fact that the pan has a value range of +/-100. No man on earth can pan that way properly.
Now, in the original documentation one can read that if you hold down the Alt Button(0x49) it sends, no matter what you have defined in the logic setup (which is here not available of course), the smallest tick size available.
So I tried to send it with Alt down but that changes nothing at all, the tick size is same coarse, and when sending 0x49 as a button press alone to DVR I also get no feedback at all that this button was pressed, same for Shift, Option, Ctrl Buttons specified. So it seems the MCU implementation of DVR does not even know these buttons exist.
Now, am I crazy and missing something here or does a Hollywood grade production suite have a completely botched MCU implementation?
Would be nice if someone had some answers for me here as I already debugged all incoming MIDI SysEx messages etc and also worked on my pan controls for a day now which is much more then all the other controls combined. I am really fed up to the limit here.
I guess they might not have much incentive to fix it because they make their money on selling their own hardware controllers. You might want to check if their HUI implementation is better but I doubt it.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
already did that with HUI, it is exactly the same sh…, extremely coarse values.
I would be interested, as I have no Faderport or alike at hand, if this is truly the case with them, too (the coarse movements esp. in pan).
Because what I found out, despite claiming they are fully MCU compatible, they have some sort of a completely (I know I use that word a lot, but it is) ridiculous implementation on top.
E.g. you cannot reach the bus channels via normal bank switch, the banks ‘end’ at the last audio channel. But, if you double click bank right fast enough you are in the bus channels then.
Or, banking does not consists of 8+8 for them, because if you have lets say 10 audio channels, bank 1 is audio 1-8, and bank 2 is not audio 9-10 and bus(es) then, but audio 3-10. Makes absolute sense…
And yea, selling their own controllers also makes sense to them, but sadly I (and I suppose many indie producers) do not have 35K at hand on the loose, where I am on top locked into a fixed layout.
I think the only recourse is for you use MIDI to mouse movements to move the controls. With that said, your controls will need to be a a fixed screen location.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
did that for a lot of things, e.g. implemented all color controls that way, because of course, there is not a single shortcut except for printer lights in whole DVR for any color wheel controls. Works like a charm, though.
But, fine pan control is hidden behind a popup and this is usually where I end with mouse controls because change this once and nothing works anymore.
This is not BMs fault of course, a crappy MCU implementation on the other hand when claiming it is fully supported is.
I see you have not more knowledge than me here, but maybe at some point someone reads this thread who has a ‘compatible’ surface and can tell me if it also only sends coarse ticks or if it sends some proprietary MIDI message for finer controls.
BM makes great products no question but this is beyond awful what they did here.