max, monome, and jit.matrix strange behavior
hello all and happy new year!
I’ve been banging my head against the wall all morning trying to figure out a problem I am having and I’ve reached my wits end. I’m hoping someone can help clear this up.
I have distilled my patch down to the minimum to recreate the problem I am having. Essentially, I get two different results from this patch if I enter information (the same information) through the monome or directly in the patch.
I am attaching the file with my post.
Thanks in advance for reading.
…here is an even more stripped down version of the patch displaying the same odd behavior…
…one last time… an even simpler example patch…
On 17 Jan 2009, at 21:18, Simone Ghetti wrote:
> …here is an even more stripped down version of the patch
> displaying the same odd behavior…
Interesting. If I put a [deferlow] between the [select] and the [uzi]
then I get the same behaviour out of both inputs. (Aren’t you lucky I
have a monome plugged in and powered up at this very moment?)
I can’t give you a definitive explanation of the difference, but
various parts of Jitter implicitly defer matrix operations to low
priority, so you’re losing the effect of the [uzi] unless you drop its
input into the low-priority thread to begin with. Have a look at the
documentation for qmetro and jit.qball (the latter is a slightly more
sanitary way of deferring Jitter operations, and works in place of the
Why do you want to uzi a matrix?
Nick Rothwell / Cassiel.com Limited
thanks for your response… to answer your questions I was looking at using jit.matrix as a way of storing information for a sequencer tied to a monome. It originally seemed like a good idea since it can potentially store a lot of information for multiple sequences and they could all be saved to one file. To be honest I am a little less familiar with all the jit objects and their associated strengths and weaknesses. I just thought that a jit.matrix would be easier to manage than multiple coll objects etc.
I guess the problem (I’m beginning to realize now) with using jit.matrix for this use is the timing aspect of getting information in and out of a matrix and trying to keep everything in time.
Am I barking up the wrong tree here? Should I ditch the matrix approach and go back to colls?
thanks for taking a look
…I realized I didn’t really answer your question about why I was using and Uzi on a matrix.
I was using a 3d matrix (16 x 16 x 96) with 7 planes per cell to store information for various sequences. Part of the interface side of the patch that deals with the monome is showing which sequences are active or contain triggers. Trigger information is found on the first plane of each cell.
As a way to find out whether a sequence was active I wanted to get the maximum cell value on plane 0 or each 16 x 16 matrix. To do that I was taking my 3D matrix and pushing it into a 2d matrix by hitting the 3D matrix with an uzi and using srcdimstart and end messages to get each of the individual 96 16×16 matrices. Then using the jit.3m object I could get the max value. The uzi also triggered a counter which gave me an index to associate with each number coming out of the jit.3m object. After that it was all patching related to feeding the information back to the monome.
As I mentioned before… I’m newer to using jitter objects so maybe my approach to getting the information out the my main 3D jit.matrix is a bit flawed.
any comments or advice would be a great and appreciated help.
ps…sorry for the long winded explanation
On 18 Jan 2009, at 00:37, Simone Ghetti wrote:
> I guess the problem (I’m beginning to realize now) with using
> jit.matrix for this use is the timing aspect of getting information
> in and out of a matrix and trying to keep everything in time.
[jit.qfaker] might help you out here.
Nick Rothwell / Cassiel.com Limited
Quote: Simone Ghetti wrote on Sun, 18 January 2009 01:37
> I guess the problem (I’m beginning to realize now) with using jit.matrix for this use is the timing aspect of getting information in and out of a matrix and trying to keep everything in time.
> Am I barking up the wrong tree here? Should I ditch the matrix approach and go back to colls?
> thanks for taking a look
I had a similar problem. I am working with the monome 256 and I was using the matrix object to store the monome data, sending it from and to colls. Either with uzi or dump messages the timing gets affected. This might work for only for a few matrixes, but not in many matrixes at the same time. Even using deferlow was not the perfect solution.
I went back to a storage system in colls and since then my timing-issues are gone and the clock is very stable in sync with the events.
Hope this helps.
Kurt, thanks for the input… I was able to use a deferlow and solve my problem. That part of the patch was not time critical. It was just sending some interface info back to the monome. So far I haven’t run into any other timing issues that effect that actual sequencer.
Just curious… why were you dumping matrices into colls? I have found that running my main matrix through other jit.matrix objects, using srcdimstart and srcdimend commands, and jit.iter work well to avoid using any colls at all.
thanks again for the input