color sequencer - ways to optimize?


    May 12 2017 | 4:48 pm
    hello max heads, I'm looking for ways to optimize this patch for better performance/CPU efficiency.
    thanks!

    • May 12 2017 | 5:16 pm
      [>~] to [edge~]?
    • May 12 2017 | 7:24 pm
      or + and zerox
    • May 12 2017 | 8:59 pm
      the edge~ seems to be working better. Can anyone tell me why these buttons are getting stuck? I'm using Max 7.3.3 on OSX 10.12.4. [screen shot attached] [patch attached above]
    • May 12 2017 | 9:56 pm
      I'd figure out a way to get rid of all those snapshot~ objects. They are big CPU hogs. At the very least, use fewer of them, and at a slower rate. I suspect some of your buttons are getting stuck because you're sending them too much data too fast:
      If possible, I'd figure out a way to map out the adsr~ data using a function or a line, and not snapshot~ing at all.
      It would probably also be a lot more efficient if you did the whole thing in a single LCD or jit. gl.sketch rather than using all those buttons.
      \M
    • May 12 2017 | 9:59 pm
      when I click on the buttons manually, they don't stick. when the LFO triggers a bang to the button, it gets stuck. that should be the same about of data, and absolutely the same amount of snapshot~ modules.
      not sure what you mean by "If possible, I'd figure out a way to map out the adsr~ data using a function or a line, and not snapshot~ing at all." the reason I'm using snapshot~ is to convert the current cell's RGB value to the buttons' bgcolor.
      I'm using buttons as this will both be "played" algorithmically and manually via a midi controller, and those 30 cells are specific to this installation. "did the whole thing in a single LCD or jit. gl.sketch" I'd be open to such things, can you show me a link to something similar? thanks for the ideas, regardless! :)
      I just checked out your patch, and it seems you've added a snapshot~ module?
    • May 12 2017 | 10:28 pm
      I'm using one snapshot~ instead of the three you were using for each adsr -- but you then have to have those R,G, and B values not be signal-rate. Just trying to minimize the use of that object for you....
      \M
    • May 13 2017 | 12:49 am
      thanks, Mattyo. I've updated the attached patch above. There are now less snapshot~ modules, CPU usage is down, but I'm still getting the stuck buttons when triggered from the LFOs. ideas, anyone?
    • May 13 2017 | 8:38 am
      to clarify, the buttons aren't really stuck - they work when clicked to trigger the envelope – it's just the "blink" circle graphic that is stuck "on". oddly, when I turn audio off, the "blink" graphics behave normally.
    • May 13 2017 | 6:47 pm
      Doesn't get stuck on my machine. Do you have overdrive on? If not, try that, and possibly using defer before you set the button color messages.
      A couple of other efficiency ideas attached.
      \M
    • May 14 2017 | 4:40 am
      Thanks, Mattyo. I updated the patch above in the 1st post. I was thinking the snapshot~ time was in ms. CPU is better at 33 samples. :) the RGB values *will* be at audio rate in future versions of the patch, so I am stuck with 3 snapshot modules per envelope. that's odd that the little "blink" circles don't get stuck on your machine. Overdrive on/off doesn't change that on my setup – neither does defer.
    • May 14 2017 | 2:16 pm
      It seems that the blink dot stays visible as long button gets *any* messages - even ones changing attributes. (I'm on Mac here).
    • May 14 2017 | 6:06 pm
      so, I updated the patch again [color-synth-a3]. It's nowhere near as complex as it will be, but I'm already running into performance/reliability issues. At 100bpm, when I go to a 64th note clock divisor, I get consistent dropouts - overdrive or no overdrive. Is this just a limitation of the counter objects, or the control scheduler?
    • May 14 2017 | 8:24 pm
    • May 14 2017 | 9:57 pm
      phenominal improvement, AK! I will spend some time really studying your changes.
    • May 21 2017 | 5:27 pm
      building on AK's 100% Max patch (no MSP audio modules), I've made quite a bit of progress in getting the functionality I need. Unfortunately, I am still getting odd incorrect color output occasionally on the cells, stuck cells, and such. It is easiest to see these issues when voice 1 & 2 are on and set to white, and both step sequencers are on. My CPU usage shows 0%, so it has nothing to do with my Mac Pro. Is there something I can do to tighten this up ? I need rock solid, exact color output on every cell, every time.
      latest patch:
    • May 22 2017 | 7:38 pm
      do you think using Gen to build the core button/color output functionality would be of benefit?