Write a jitter matrix file (.jxf) with [jit.matrixset] ?

Hmm.. that only seems workable if I generate a folder full of hundreds of files. I'm also having trouble getting [jit.matrixset] to work the way I want and I can't tell if the issue is related to 64-bit mode (considering that other objects such as [jit.record] aren't compatible with 64-bit mode).

Is there a way to combine .jxf files into a single file?

If not, which exportable video format will afford me the greatest precision for channel values?

Anyone? This is what I'm talking about... What is best way to save the packed videos.. either with float32 or float64 precision .. preferably as a single file.

float32 version (3 vids to 1): -

float64 version (6 vids to 1):

Like this? Mostly lifted from matrixset help file (caveats: not really tested for issues. Setting the matrix dimensions would need to be done 'properly' and this eg set to capture 30 frames: Not certain, but high frame counts may result in memory issues...)

(flaot32 version)

Okay got it.. Thank you very much.

This was amazingly frustrating btw. I still couldn't figure it out when I first looked at your patch. I tried to write 240 'frames' of [jit.matrixset] to disk only to get an OS error that I was running out of space. Obviously I was trying to save 240 sets of matrices. I couldn't find a single reference in the docs or on the forum that clearly explains that the .jxf file saved by [jit.matrixset] is different than the .jxf files saved by [jit.matrix]. They are, after all the same file type - not to mention the reference docs for [jit.matrix] and [jit.matrixset] have the same definition for the 'write' message. That is akin to bundling 240 .doc files into a single file and calling it a .doc file. Amazing. One of the few times I have been legit pissed off about the shitty documentation. /rant

For anyone else experiencing similar confusion... after indexing the matrix frames in [jit.matrixset], the entire set of frames can be written to disk as a single .jxf file and later read by [jit.matrixset]. Each frame is then played back by prepending the frame number with the "outputmatrix" message. However, the same .jxf file can not, be properly read and played back by [jit.matrix]. There also doesn't appear to be a way to tell the difference between a file saved by [jit.matrix] and [jit.matrixset].

Hey both, thanks a lot for this. But I still have a problem with the playback. When I load the .jxf file that I recorded with jit.matrixset (using write message) into a "new" jit.matrixset (using read message) I don't get anything out. Here is a simple example using only a 3 plane float32 matrix...I am still trying to find a way to record a geometry matrix as some sort of a sequence/"video".

PS: Is Max still limited to 2GB of ram as I read in a topic from 2011 entitled limits to jit.matrixset? https://cycling74.com/forums/limits-to-jit-matrixset/

Hmm... Writing the jxf file and reading it into the 'new' matrixset using your posted patch works without issue here.

RE: the 2GB limit- that would be a consequence of Max probably being a 32bit app in 2011. Using it in 64bit mode which is now an option would overcome that limitation - provided you aren't running any 32 bit externals and had enough RAM available.

Also, following a link from the forum thread you posted, it turns out there is a discussion regarding how to use jit.matrix to store a sequence of frames (and in one case write multiple .jxf files) that seems somewhat relevant to this inquiry https://cycling74.com/forums/capture-video-to-a-buffer-then-shuttle-around-in-it/

@t Everything spectro said. Works fine here in 64-bit mode. 32-bit mode is limited to 4gb of RAM of which only 2gb are available to Max. Amazingly, while 32-bit computers/apps are limited to 4gb of RAM, 64-bit has a theoretical upper limit of (drumroll...) 18.5 billion gigabytes.

edit: Your patch works for me in 32bit mode too..

ok, i tried it on another computer with Yosemite OSX and it works! Thanks a lot guys, much much appreciated! All my troubles seem so far away...almost:)

However the playback still doesn't work on 10.9.5...which is on my machine which I really don't want to upgrade. Could anyone from Cycling team confirm if it is definitely a OS problem?

I assume you guys don't use 10.9.5?

And once again, thanks million times! Almost done with my nightmare...

PS: tested in Max 7.1 (64 bit mode) and a previous version (32 and 64 bit mode)

I'm on 10.10.5 Send a quite note to support@cycling74.com.. otherwise they probably won't see this.

Hey METAMAX, can you double check if the patch really works in 64 bit mode of Max? I got a reply from support saying "This is only currently supported in 32 bit."

In the meantime I upgraded my OSX to 10.10.5 and as I realised now it works only in 32bit mode...:-/ But then again, I managed to create a file that is around 6GB but when I tried to push it a little further (more frames--->bigger size) Max froze...so I am really confused now

Okay, friend... here's the down low.

[jit.matrixset] is fully supported in 32-bit and 64-bit mode. Amongst other things, it is currently able to index and output matrix sets of any data type within a patch and to write a matrix set of any data type to disk as a .jxf file. There is, however, a current 64-bit bug that prevents [jit.matrixset] from reading indexed matrices of any data type from disk (reference ticket #9683 if you contact support about the issue).

The ability to process float64 data can be confirmed in 64-bit mode by indexing float64 input and outputting it within the patch and/or writing a .jxf file to disk and reading it with a standard [jit.matrix] object. [jit.matrix] displays the first indexed frame in full float64 precision.

Additionally, .jxf matrix sets that are written to disk in 64-bit mode are readable by [jit.matrixset] in 32-bit mode with the only caveat being that float64 data will be truncated to float32.

Regarding freeze-ups in 32-bit mode:

I think this was answered earlier when addressing the inherent RAM limitations of 32-bit applications. If you are creating 6GB files, you are likely running out of available RAM. Until the 64-bit bug is fixed, the only workaround I can think of is to write your float32 matrix sets to disk in 64-bit mode. This will make more RAM available to Max and might allow you to save your complete set. However, you will need to revert to 32-bit mode to read what you saved. I haven't tested this though. You may run into the same RAM limitations when reading your file from disk... Good luck!

Thanks for this explanation!

However, let me share with you a strategy for creating relatively big files with 32bit version. Yesterday I wrote and read a 7.99GB file with 32bit Max! I don't understand these things, even from Cycling support I was told that 2GB should be the limit (both for read and write), but it seems that 2GB is not the limit. Also I was not aiming for 7.99, the size was coincidental so maybe 8GB is the limit:)

So what I wanted/needed to create was a [jit.matrixset 40000 3 float32 129 129]. So 3 planes, 129x129 size and 40000 frames (which ends up in 7.99GB). If I create that object:

[jit.matrixset 40000 3 float32 129 129]....Max freezes forever

But if I first create the same object with one plane

[jit.matrixset 40000 1 float32 129 129]

and then change number 1 to 3:

[jit.matrixset 40000 3 float32 129 129], (the same as at the beginning) the Max does not freeze. It takes about 10 seconds to create an object but it works.

I tried this method on two machines, one with 16GB of ram and one with 28GB (or there somewhere). With both machines Max froze if I tried to initialise [jit.matrixset 40000 3 float32 129 129]. And then again on both machines (all in 32bit mode) [jit.matrixset 40000 3 float32 129 129] was created in around 10 seconds AFTER I created a 1 plane version first.

I thought that the file might be corrupted in some way so I watched the whole recording (like idiot:) and there were no glitches, everything smooth and as it should be...

Cool, I'll keep that in mind... Glad you got everything worked out.