#1

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?

Thx

#2

@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 …


----------begin_max5_patcher----------
934.3oc0X98aZCCDG+Y3uhn7LqB6Pbf8vT2a6+gopJShG0UI1YNN.cU8+8Ye
ND9U.xRgzNoRr7gI4tO97ceadc3.+4x0rBeuu58SuACdc3fAfIqgAUyG3mQW
GmRKfk4GKyxXBs+H22oYq0f8m456xnZEeM1MDqUoaVEOAVib9yeAOdiQQYFW
jxzv8EUYrP+RJCV7NKSVp2rtwUVyo53m3hEOpXwZm+iIQ2MdjGNzdEQPvDiI
uGp9M+RJzE7+.2dzz6Fas91vg1KiZYzaix7UbQhbUCwVP3FiRQQrhwD65xtn
P+RNy4ulHz7o16ZDG6G73yD7XLDuSGCQ+3sCdOzg3TvVYBni1jyUrblHwqfo
aZqMxeGRKnYtMxuq3z5Lgigv4AvkxGPmFIlzgvQdAAPVQzD.O3SkNf6T5v4w
TSHZ5mJDEBTIHJvNDF1iHxdPhqYplXzrtvnQs57zkXUvkXEdFwNLgbKX0YKb
R7q8MkgIF18HSPm6Bm5xhJVgo5LUykhc88YvNLYVUERR8Ps6eDQS4EZKQgwy
SUZoVVG5mjzJ4J2uhTYHVlVlI12VqK341Nlfc6JgSqGtl0611TyqPSUZOjW7
STkwcM+0vdDp4i2+fktjo4wzSl9ZdPO5dPWgj3KRMLFRGPgtdFi6sS7pEywl
8bZSnqKMO5WrgPHaGkHWtVvonVv0lZxbu6Me9l28KoolckoMgO7sBe3qF9bf
CgmcKpcddkYQjOZkYHxXaxy6VYVoQ8cYSQHtckdnooxUIJ5h8USe5VJGAGtP
eb2VSu7rp+OB+3TYAy90irWjFoP0SLBG0F7Tb6ZSaSurx9fbsp1Bck0Z4hEF
+nAXG32Uxci0xgPah32QbehZQ+1DnJoQQcSDYRG67MmJV7Nq7bYAtPZ.Irm6
1sPQm2DpB+uPjPDT1ZRz+Bzf0XTLJN7cJ.OEq88IYgrTEuI71zFya6iJgUXJ
W.pY2cQS2aQOwSR1uddBuvdVDPdy6os1ehZi+f6M+wl6bQ+w1r6r9SFOIWZJ
FUsIQBbclH2EEZE1f1Nc6SpeCgC39MEoSZCRC6O+InM9yj9yerY2nOO7w95A
tHevS6W+4R7A2e4yGD5M6Oj9ychtFaWGTwJB5JEPfFUtxWvjaP4JTavYPXWp
3hIt2CiqfKL6iJ.N3PU6SHbc7o44KYphp6I3JFUROKU1oQifobgaJH7vWwVx
2rdPMuOUYzgnMhPJUNcKqINMk9YxDlRTxAAGCsO42F9WI3lqGB
-----------end_max5_patcher-----------
1 Like
#3

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.

for reference:

Overdrive
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.

#4

@ithkaa thanks!

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.

#5

maybe this example using jit.matrix for paging helps:
http://archive.monome.org/docs/dev:max:paging

#6

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 :grin:

2 Likes