jit.matrix 8 by 7 pixels slow?
Not really sure why this patch is awfully slow. If I adjust one of the pixels individually (in p pixel, which is in p pixelboard) it runs great and smooth. If I adjust them all together via the main color picker I already get major slowdowns (around 6fps). If the midi signal from the midi piano (yamaha p140) controls the pixels it becomes even more slow (fps says 2000 but the whole UI is just not responding).
I first thought it would be the 53 lcd objects that were destroying performance, but after stripping the patch to the bare minimum it still has the same performance. I attached both the original and the stripped version to this post.
This is on a 2.4GHz i7 MacBook Pro, 16GB RAM and Radeon HD 6770M 1024 MB. MacOS X 10.7.5. Max 6.0.7.
So, some rules of thumb with Max and Jitter in general.
Anyplace where you have data processes, and "inline" user interface objects like live dial, flonum, etc attached to constant messaging, is going to cause slowdowns when those objects are forced to draw their user interface in response to input messages. This is true *even if the patch is closed, the object is hidden, and if its layered 20 sub-patches down*. This is because Max does not draw or handle UI updates separately from the other processing and message passing it has to do.
Solution – Do not use live UI objects to introspect data. If you must have them, make them set, and update slowly with a qlim at non realtime speeds. If you are using flonum etc to clamp values to min and max, do it another way, with other objects. Really. Replace every live.dial and flownum, gswitch with something else more appropriate that lacks a live updating UI – I can almost guarantee you will see huge performance deltas.
Thanks for the tip! First thing in the morning is a major overhaul.
I had expected that Max would do all of this in a separate thread. Maybe some day later. :)
Is there some place where I can read in to these kind of things? I read almost all of the tuts and docs but it nowhere mentions this. Seems to me a pretty important thing before one starts building complicated multilayered patches.
It’s scattered all over the forum and on some webpages like Vade’s: http://abstrakt.vade.info/?p=147
I wanna start collecting all these Jitter techniques and best-practices in the new wiki (http://cycling74.com/wiki/index.php?title=Main_Page) so there’s 1 central reference point. Didn’t get around to set it up yet.
Ok, I know that site from Vade. Even learned how to build a good Jitter patch from it. Just forgot about the whole UI updating thing below it.
*bangs head against table.
I sure want to chime in to the Wiki, didn’t even know it existed! When it iss less busy I’ll probably update some Kinect parts. :)
Stripped down everything from all the live.dails, flonums, swatches, lcd’s and whatnot was updating over time. Performance did improve but when I let the musician play something more intense then the Flea Waltz the frame rate starts to drop, quickly. In the end he needs to play Chopin’s Fantasie Impromptu through this system. I know, quite a lot of hits on that piano, but never imagined that it would be this heavy for Max.
Sometimes when optimizing code, you have to look different approaches. setcell can be quite slow, as you are seeing. Perhaps another way of thinking about this, is that you want to populate or fill a matrix with HSV values, and then display it as RGB.
It is going to be far more optimal to use jit.fill, and populate and set a giant list of HSV values, than making an HSV value, converting to RGB, setting the matrix.
Think about the steps.
a) For (every value I want to insert)
a) make a HSV color
b) Convert it to RGB
c) set the matrix value at that point)
b) send to syphon.
Thats message overhead for every cell, each part in the for loop does its own individual message, integer calculation and does not operate "widely" in a large batch.
Alternatively you can:
a) For (every value I want to insert)
a) append to a list of HSL
b) Use list to fill a matrix.
c) convert matrix to RGB
d) send to syphon.
This APPEARS to be more steps, but you a) fill the matrix once, in a batch. b) convert the matrix to RGB once, in a batch.
I suspect this help. Its not what you want to do that should be slow, its *how* you are doing it.
Tools to look at use: Table or Coll, jit.fill, jit.hsl2rgb
Puzzling… Not sure but one thing I’m seeing is in [pixel], the message box with (setcell 0 0 val 0 0 0) is still updating in realtime, driven by the [line].
The performance is over and I did make it work in the end! Not entirely in Max as I wanted to, but with the help of VDMX, my old trustworthy companion. I never imagined that I would ever make 54 layers with it. :)
So, how I did it in the end is the same as I had before except that where I normally would sent the values to a Matrix (or jit.fill) I now send them by OSC to VDMX. VDMX takes care of the rendering and sends the output to MadMapper. I could do the mapping in VDMX as well, but time was short and I had to rethink the processing over again of I would (no option to turn anti aliasing off for the main output for example). I did try Vade’s options but had to less time to dive in to it.
One thing though (that I also couldn’t find on the boards here) is that when I use a coll the output seems to be not working for the line object. I first have to put it in to a message and bang that message before it works.
Here is an updated version. Thanks vade and dtr for the help so far. :)
Forums > Jitter