I’ve noticed a 16x16 matrixctrl can cause slowdown in m4l when refreshing leds, i usually have to defer the output, so i’m trying to switch over to jit.matrix. I remember reading on the old monome forum that jit.matrix is much more efficient than matrixctrl for storing / retrieving led states, so hopefully that would fix the slowdown.
Does anyone have any experience with this, mainly converting matrixctrl formatted messages (horiz-coodinate, vert-coordinate, 0/1) to work with jit.matrix, then convert the output back to matrixctrl-style. I think i need to use jit.fiill / jit.spill but i can’t figure out how. Is there an example patch of this posted somewhere?
@elquinto here’s a patch that does jit.matrix to matrixctrl. My idea was to use the grid as a 16x16 screen for a live feed, hence the jit.grab. I’m not at all familiar with jitter so there might be better ways to do this. looking forward to seeing more jitter-based approaches …
I’d avoid any UI objects (as matrixctrl for instance) in that kind of stuff.
Indeed, Max for Live is running with the Scheduler in Overdrive mode and using UI in that case (and specifically when you feed UI on high rate of message) can suck CPU a lot.
When Overdrive is enabled, Max gives priority to timing and MIDI processing over screen drawing and user interface tasks such as responding to mouse clicks. As a general rule: if you are primarily going to be using Max for MIDI or audio processing, Overdrive should be enabled. If you are primarily going to be using Jitter, Overdrive should be disabled. In addition, the debugging features of Max only work if overdrive is disabled.
i was just checking out Grid Monitor in Beap, which i found uses jit.matrix to refresh leds. i’m interested in any other ways people are using jit.matrix for monome patching. it seems really useful.
maybe this example using jit.matrix for paging helps:
This is old, but FYI, if you downsample the matrix first and then perform your thresholding (jit.matrix then jit.op), you save a bit on cpu processing power