we don’t poll encoders using any of those things, just normal GPIO file handles.
[ https://github.com/monome/norns/blob/master/matron/src/hardware/gpio.c ]
lua interpreter lives in the same process as MIDI / HID / GPIO / TTY commuication, so these things are low overhead. incoming events are pushed to a queue and handled by the lua main thread and that’s that.
communication with supercollider uses OSC b/c that is the way of supercollider.
crone also uses OSC, b/c it was migrated from supercollider. but replacing this with more appropriate local IPC is a high priority.
that is how norns lua layer works. we wrap stdio in websockets and that is how it is plumbed to the web UI. this would be pretty easy to modify if you want different plumbing, or maybe use the same plumbing with different interpreter process.
anyways yeah it sounds like we should definitely break out hardware i/o to a library. buuut… (@PaulBatchelor @ngwese) i’m not super clear on the “right” way to structure that interface. specifically:
- should the lib maintain an event thread and queue, as is done now, and the lib user implements a single-threaded handler function?
- or, something else, like user lib handling each event as its generated (from different threads)?
(i’ve looked a bit at the libmatron branch but do not yet grok the strategy.)
(ed: oh - i see that there is a new callback passed to
event_data_new for freeing the data… is that “just” for tidiness?)
re: cairo. we also need to break this out to a dedicated thread / event loop. i’m now thinking it should maybe be a separate process altogether.
read/write to the raw framebuffer like you would /dev/fb.
should be trivial right now. the framebuffer is right there at
/dev/fb0 and it’s all yours if you don’t laumch the