jit.matrix reset to defaults on name change?
I found a problem that has me puzzled.
I use the message ‘name X’ (in my case, X = "fftdata512", "fftdata1024", etc.) to rename a jit.matrix which I already initialized as 2-plane float32 through typed-in arguments. The matrix was not named yet.
After the renaming, the matrix is 4-plane char (indeed, the defaults for jit.matrix).
This happens inside a spectral subpatch (I’m using multiple copies, that’s why I want to name the matrix dynamically). I’m using max 4.6.3 on OSX.
Any idea under what circumstances this would happen? Of course I can make it work by explicitly setting all the attributes back after renaming, but I’m just wondering why this happens?
i just tried this and could not reproduce.
please provide and example patch and all the relevant computer specs
-rob
Thanks for your reaction.
I took the concerned objects out of their context (big program with lots of components and subpatches) into an example patch, stripping away all parts that should not interfere with this. However, in the resulting patch I cannot reproduce the problem.
Going back to the original patch, the problem is still there sometimes (it doesn’t happen always and not in the same manner).
So it must be some issue in the bigger patch. I will not send you this because finding the cause of the problem in there might take very long. Maybe I will take a look at it again, if so I will post here.
I got the feeling it has to do with the memory for matrices that is somehow not flushed completely when closing patches. I think this because sometimes when I reopen the patch, the matrix contains the same values as before closing the patch (I’m not saving anything). These strange things seem to co-occur. On the other hand, closing and restarting Max doesn’t always remove the problem either. I’m in Mac OS 10.4.11, 2 GHz Intel Core 2 Duo, 1 GB RAM, using Max 4.6.3, jitter 1.6.3, keyserver version.
I have the same problem. I use my patch as an abstraction, and the Jitter matrices are named using an argument on load.
However, they start as 2 plane float32 data, and end up as 4 plane char data which doesn’t work properly.
For now, I’ve just added a workaround but it is pretty annoying.
Bizarrely, as maarten_wez says, it only happens occasionally. Also, it only seems to happen with certain names. In my patch, I wanted to dynamically give the matrices argument_Mix (depending on the argument).
When it was named ‘FFTone_Mix’ it resulted in the matrix reverting back to 4-plane, char data.
Here is an example, it starts off as float32 and if you change the name to ‘FFTone_Mix’ it ends up as 4-plane, char.
Apologies for the triple post….
I restarted my computer and no longer got the bug…. Which seems pretty weird, however, it seems more worrying since it’s obviously not a problem with using particular names, but something else.
Sounds like it may be an order of operations scenario. With your simple patch, I can’t reproduce. However, please see the following patch which demonstrates that if you tell an empty jit.matrix to be the name in question before setting one which has arguments, the one with arguments becomes a reference to the default 4 char 1 1 matrix rather than the other way around.
Kind of confusing, but this is how named buffer~s and colls work too. You need to be sensitive to that if you are using multiple references.
Please let us know if your problem seems to be related to something other than this hypothetical explanation.
Thanks,
Joshua
Yer I completely appreciate that the order of events is crucial. However, in my original patch, there appeared to be no other matrix that the name was referring to. When I uploaded that patch, there were no other Max windows open and I was getting the problem, it seemed that ‘FFTone_Mix’ had been assigned to [4 char] type even though the matrix no longer existed.
I can’t replicate this every time, but sometimes Max ‘remembers’ that one name was once assigned to a particular matrix type. Like I say, this doesn’t seem to happen every time but I have definitely had it occur a few times.
I have tested and re-tested this problem that I’ve been having. As maarten_wez says, it has something to do with the name being stored even after the patch is closed. The only way I’ve been able to simulate this is by doing a fairly long-winded process. This process involves deleting the matrix with a certain name and having it’s datatype remain associated with it.
Below is an example patch with (hopefully) demonstrates this.
Thanks. I’m able to reproduce and am investigating. It actually seems like it might be related to jit.matrixinfo, route, or the setting of the message boxes, as the following patch doesn’t have the same issues, and I’ve never encountered this problem before in other patches.
Seems like a very subtle memory corruption bug, or some problems in jit.matrixinfo. Will try to fix for the next release.
Thanks for spotting this,
Joshua
Errr. Scratch that. It seems like it’s still reproducible by repeating the steps a few times even without the jit.matrixinfo object in the patch. Tricky problem to track down.
Yer that’s one of the problems I had yesterday. The problem seemed to disappear all of a sudden. I wouldn’t have noticed it, if my patch didn’t start behaving weirdly.
I think one of the main issues is that the name remains allocated to the matrix type even after the patch is closed. So you could start a new patch, and you wouldn’t be able to dynamically rename your matrices with that name.
Finally solved this one for the next release. Thanks for finding it and providing clear steps to reproduce.