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.
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?
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....
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.
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.
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?
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.