replicating [preset] for [jit.lcd]
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:
Thanks!
I'd suggest jit.matrixset.
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.
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.
I'm not aware of anything 'inefficient' about jit.matrixset, but if you prefer a 3D matrix, that'd work, too.
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.
>> ... 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.
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!