pattrstorage CPU usage

    Sep 30 2009 | 11:30 am
    Hi, I've build a very large patch, controlling audio, video and lighting using a Enttec DMXusbPro with the appropriate object. In running the patch on a new MacPro, Nehalem Quad 2.93, with 6 gigs of RAM. I can run several video and audio instances without any problem, but when I integrate the lighting everything gets slower. The lighting patch is made of 64 float box controlled by a pattrstorage. In order to optimize the process, I use it "@change 1". Everything is going fine... Is pattrstorage's expensive on CPU? The patch is too big to post it here, but is there any obvious way I can improve the pattrstorage process? Thanks a lot!

    • Apr 14 2010 | 4:59 pm
      I second this question about pattrstorage. I have a patch with complex interpolation between pattrstorage presets and I think it eats much CPU. I am wondering if I should replace pattrstorage with lists, colls and vexpr objects.
    • Apr 15 2010 | 1:25 am
      I wonder if replacing the 64 floats with a multislider would help, though maybe for the interface you want the individual boxes. Either way, you could try [speedlim 50] on the values, this has helped me in the past with similar bogging down, and you still get very smooth values (alter your msec to suit of course). This lets the overal processing keep up better, by not trying to send every millisecond (which is totally not needed for smoothness). With a multislider you could speedlim the whole list at once, and maybe pull some quantizing/beat-matching tricks in the process.
      Don't know if the serial output is the bottleneck in the lighting case, but it could be.
    • Apr 15 2010 | 1:30 am
      You could also go with a couple of jit.matrixsets instead of pattrstorage for your "stored slots" (jit.fill your values and store them), then use a jit.xfade for interpolation. Then you could also use other jit.matrix FX to see what happens to your non-video data. could be interesting... alter the "contrast" of your data? That would give some results which would be tough to get any other way. Or a jit.rota / zoom, which would give you various repeats of parts of the data... etc... depending on what you're using it for, it could be quite something.