Help me replace matrixctl with live.grid?
Hi.
When I was starting my latest patch I couldn’t figure out how to configure a live.grid the way I wanted and ended up using a matrixctl. Now I’ve sussed the matrix mode of live.grid and want to go back to that but my patcher is using the matrixctl approach of sending out changes e.g. (row col sel) -> (1 1 0) rather than the live.grid approach of sending out the entire configured matrix on each change.
Does anyone know how to get live.grid to be compatible with matrixctl and send messages for each cell change?
Thanks,
Matt
hope this helps
(in case you dont know, copy the code below. go to max -> file -> new from clipboard.)
Hi Coffeencigs.
I’m very grateful to for you trying to help me, thank you. Unfortunately I’ve just realised how my request could be misinterpreted.
In my device I am using a matrixctl to manage connections among other objects. I ended up using it because I thought I couldn’t get live.grid to do what I want.
Now I’ve learned enough about live.grid and want to replace the matrixctl I am using with a live.grid.
The problem is that matrixctl sends out a message for each cell change as a tuple (row,col,state) whereas live.grid – so far as I can see – will only send out a list of all cells switched on as [(row,col),(row,col),(row,col),....].
The rest of my device has been designed around the matrixctl approach and is expecting single cell changes. I’m flinching at the prospect of having to re-engineer the device to work with live.grid.
To do this I am probably going to have to create something that remembers the state of the live.grid and compares it’s output with previous states in order to generate single cell messages but I see complications ahead.
So I am hoping that maybe I have missed a way to make live.grid emit single cell state change messages like matrixctl. Or that someone might have already gone down this road and made an adapter.
If live.grid in matrix mode really isn’t drop-in-compatible with matrixctl then I’m pretty ticked off the Ableton/C’74 for the inconsistency.
Anyway thanks again for your help and if you have any further advice I’d be grateful.
Matt
I’ve written an email to C’74 support to ask them why:
live.grid (in matrix mode) has a different output system to matrixctl
live.grid uses 1-based addressing instead of 0-based addressing throwing out any notion of consistency
live.grid uses (1,1) as bottom left while matrixctl uses (0,) as top-left so they are not address compatible
It’s hard to believe this sort of inconsistency could be the product of chance alone. This kind of work requires a devious mind.
Matt
i can guess what support’s answer will be:
live.grid states within the help file that it is a UI grid of ‘steps’ and it is ‘designed for use with the chucker~ object’
whereas matrixctrl is more open-ended(does not readily confine itself to specific step/direction/transposition style use but is rather a simple matrix of switches(or dials))
they don’t work readily within the same message protocol because they are meant to do completely different things, otherwise, you wouldn’t need one or the other included in Max.
if you’re unable to reverse coffeencigs patch to get live.grid to change matrixctrl, then you can try to learn more about the [zl] object to help you process the lists coming from live.grid…
otherwise, you should really post your patch so far so we know exactly what you’re trying to do…
hope that helps.
Yeah I guess so.
It just seems like when you put the live.grid into matrix mode it would have made a lot of sense to make it compatible with the matrixctl object.
I think I can figure out an adapter to make it compatible, I just hoping I wouldn’t have to. Or I suppose I can re-engineer the rest of the patch state to take complete updates rather than individual cell updates. That’s probably the better long-term option but more work now.
Hey ho.
Thanks anyway guys.
Matt
I’ve built an adapter that takes the output from a live.grid (in matrix mode) and makes it suitable for patches that were, previously, expecting the output from a matrixctl.
It’s not really generic enough to just "drop in" into any other patch as I made some choices about interpreting the output specific to my situation (the size of my matrix being the principal one), but it should be pretty easy to re-use.
There were two obvious approaches to this problem one of which would have kept the matrixctl behaviour of a single message (col,row,state) for each cell change, and another that involves resetting the entire matrix on each cell change.
The former would have involved redundantly maintaining state inside the patch. Since I didn’t expect performance to be an issue I went for the simpler approach which outputs the entire state of the matrix, as a series of messages, on each cell change.
Any comments on my patching style or solution welcomed:
Regards,
Matt