Forums > Jitter

replicating [preset] for [jit.lcd]

August 18, 2011 | 10:50 pm

Has anyone developed a reliable way to store and recall matrices from jit.lcd? I’m looking for essentially the same functionality as [preset] does for UI objects, i.e. the ability to write to and recall an extensible number of values (in this case matrices).

I spent way too much time this afternoon trying to patch together a solution using a number of different methods. I had a great amount of difficulty getting the event order correct when using several copies of jit.matrix with gates, which would also make it a great pain to extend the number of presets. Also tried using [poly~], but had some getting the control right there as well.

I know when I get this involved in solving a semantic problem in patching someone out there probably has a more elegant solution. Here’s the patch I’m working from:

– Pasted Max Patch, click to expand. –


August 18, 2011 | 11:26 pm

I’d suggest jit.matrixset.

August 18, 2011 | 11:28 pm

Well, I seem to remember that a 3d matrix is generally more efficient, but it’s the control logic I’m having trouble with– not the choice of storage container.

August 19, 2011 | 12:05 am

if you like the UI of [preset], you could just use the UI part of it: connect a dummy, hidden number box to it so that’s all it stores, and you don’t care what the value is. Then use the "preset number when stored" and "recalled" outlets of the [preset] object itself to manually store/recall using jit.matrixset.

August 19, 2011 | 12:23 am

I’m not aware of anything ‘inefficient’ about jit.matrixset, but if you prefer a 3D matrix, that’d work, too.

– Pasted Max Patch, click to expand. –

August 19, 2011 | 12:26 am

Thanks, Christopher. Your patch made me realize the problem I was having had to do with the way I was implementing the drawing since it requires jit.lcd to constantly be banged. Unfortunately, the drawing in your patch doesn’t function correctly. I want it to draw as a pen on paper would. Any ideas? If not, I’ll examine it closer tomorrow.

And I believe I heard about not using jit.matrixset to store 3d matrices from a C74 employee. Maybe one of them can chime in. Anyway, that was in regard to a video buffer, so performance shouldn’t at all be an issue in this application.

August 19, 2011 | 1:09 am

>> … the drawing in your patch doesn’t function correctly.

The drawing method in my patch was just a quick hack to fill the matrices with something. It wasn’t intended to be anything interesting.

>> .. I believe I heard about not using jit.matrixset to store 3d matrices …

I thought you meant that you prefered to use a 3D matrix to serve as a set of 2D matrices INSTEAD of using jit.matrixset — and that’s what I meant in my response.

August 19, 2011 | 1:21 am

No, you understood me correctly about jit.matrixset– I meant to say the ONLY reason you should use it is for storing 3d matrices.

I seem to remember it taking me a while to get the drawing right and luckily I save it from a couple years ago. Your patch seems to get the storage right even if I hook up a metro to jit.lcd. I think that’s because I didn’t put the jit.matrix in between. Thanks!

Viewing 8 posts - 1 through 8 (of 8 total)