`monome_event_next` sometimes produces odd results

[ryleelyman]

Here's a little program. All it does is print the event data received by calling monome_event_next when poll says that there's data to read.

#include "monome.h"
#include <poll.h>
#include <stdio.h>

int main() {
  // to actually use this on your machine, you'd have to change the path to match your grid.
  monome_t *m = monome_open("/dev/tty.usbmodemm44642411");
  int fd = monome_get_fd(m);
  monome_event_t e;
  e.monome = m;
  do {
    struct pollfd fds;
    fds.fd = fd;
    fds.events = POLLIN;
    fds.revents = 0;
    if (poll(&fds, 1, 1) < 0) {
      fprintf(stderr, "libmonome: error in poll()");
      break;
    }
    if (monome_event_next(m, &e) < 1)
      continue;
    switch (e.event_type) {
    case MONOME_BUTTON_DOWN:
      fprintf(stderr, "%d,  %d,  %d\n", e.grid.x, e.grid.y, 1);
      break;
    case MONOME_BUTTON_UP:
      fprintf(stderr, "%d,  %d,  %d\n", e.grid.x, e.grid.y, 0);
      break;
    default: break;
    }
  } while (1);
  monome_close(m);
  return 0;
}

What's bizarre is that if I mash the keys on my 128 grid, I can get values in the 30s for x and/or y. Repeatedly pressing a key also sometimes results in two presses in a row or two releases in a row, rather than them being properly interleaved.

I'd love to be better able to use monome_event_next to avoid this behavior! I tried reproducing it in Max (presumably with serialosc) and was unable to... but it's not clear to me what's different there.

[tehn]

could you tell me the edition of your grid? and also the OS version and machine you're using?

have you tried a version of the above example with registered callbacks instead? this would perhaps rule out a bunch of possible culprits, narrowing it down to just the next_event implementation.

[ryleelyman]

Ahhh, I think what is happening is that serialosc and this program are fighting, and this program is losing. If I disable serialosc, I'm no longer able to reproduce the issue.

but! this is with my 2022 grid on an M1 MBP running MacOS 13.3.1.

anyway, this suggests I should refactor my program to go through serialosc.

[tehn]

oh i'm surprised that you got any data at all--- i thought if serialosc was running that libmonome wouldn't be able to claim the serial port again and fail.

glad you spotted the issue.

isms also started out with just libmonome, but moving over to using serialosc proved very nice

On Sun, Jun 18, 2023 at 2:18 PM Rylee Alanza Lyman @.***> wrote:

Ahhh, I think what is happening is that serialosc and this program are fighting, and this program is losing. If I disable serialosc, I'm no longer able to reproduce the issue.

but! this is with my 2022 grid on an M1 MBP running MacOS 13.3.1.

anyway, this suggests I should refactor my program to go through serialosc.

— Reply to this email directly, view it on GitHub https://github.com/monome/libmonome/issues/78#issuecomment-1596227750, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB4I4A3GL5YPOQNX2AZBULXL5A7JANCNFSM6AAAAAAZLAHZBA . You are receiving this because you commented.Message ID: @.***>