Hey, Luis.
I have new information that will hopefully help your devs reproduce and fix this.
In the live rig, I use a laptop, but I plug a monitor into the extra vga port and view from that rather than the laptop screen. In studio A, I have a 42" screen but it’s coming vga out of an old school kvm that doesn’t support hdmi.
On both of these boxes, if I go to Device setup / Video / Video Player, I see nothing but an error message in red text:
Please update your graphics card driver or switch to a more effective graphics
On both of these boxes, I can reproduce the problem as described. Additionally, I have a couple of keyboard shortcuts mapped to horizontal zoom in / out. If I lean on that key, it zips along for a second and then the screen update becomes jerky. It appears to update about once every 500ms or so. The lag time feels exactly like the delay when I press the next / previous bar keys on my TP.
I use the studio B box for video editing and consequently have a moderately high end video card. When I bring up video settings on that box, I don’t get the error, I get the normal video player settings. And I can’t reproduce the bug on this box.
From this, it seems clear that this is another problem related to the video card since the two boxes with unhappy video player messages have the bug, the one that’s content with its card doesn’t.
If you’ll permit me to be presumptious for moment, I have the following thoughts from a developers perspective (I grew up on C, then C++, etc. and have been doing it for 25 years). My question about why a midi drum editor would care about video came to mind as I was looking at the zoom in / out bug described above. Especially when you’re zooming in, that’s a very, very busy screen in terms of all the lines that have to be drawn, etc. Much more so than with the piano roll or list editor. I think this may be the key to the drum editor interacting with the video system.
Back in ancient times (DOS 3.1 if I recall correctly), writing graphics to a character mode screen required a few different techniques depending on your needs, including bios calls, interrupts and writing straight to video memory. Each performed better /worse than the others, so you chose accordingly.
I mention this bit of massively obsolete programming practice for no other reason than to illustrate that when faced with the need to do higher performance screen updates, even modern devs will steer away from the typical Windows APIs for drawing (or it’s Mac equivalent) and instead will look for ways to write to a lower level of the video subsystem in order to get the desired update speed.
For a grid as dense and busy as the zoomed out drum editor, the draw to / line to routines probably looked fairly slow and drippy (I’d also image you’re using some kind of cross platform library to cope with Windows / Mac, and its drawing routines will be the lowest common denominator rather than high speed). I’m willing to bet that if your guys check the coding infrastructure that’s used to draw and update the drum screen, at the lowest level they’ll find that it’s not using the same stuff as the piano roll & list editor, and very likely is accessing lower level video APIs that make assumptions about the quality of the card / driver.
I’m guessing that when an acceptable level of driver isn’t found, as in my 2 out of 3 boxes, it drops down to some default graphics routines and things go badly. For all those people who have had other video related problems with this screen, it might be worth your while to see if they have the video error message. I’m willing to bet that they do.
Anyway, quite presumptious since I know nothing about your code (and programmers do tend to get annoyed at such arrogance), but this is the closest thing to a smoking gun I can give you. At the very least, I think if your guys test on boxes with sub par video cards, they can reproduce this in a debugger and fix it (if you can’t reproduce it in a debugger, you’re usually screwed). If they can’t get hold of a box without a good video card they can try a) using their laptop but plugging in an external vga monitor as I do or b) try logging into the box via Windows Remote Desktop, which also downscales the graphics. Can’t confirm that RD will reproduce the bug, but I know the laptop monitor thing is likely.
If I can be of any further help on this, let me know and I’m happy to do what I can.
Thanks!