[>~] to [edge~]?

or + and zerox

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]

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

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

\M

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?

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.

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

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.

It seems that the blink dot stays visible as long button gets *any* messages - even ones changing attributes. (I'm on Mac here).

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?

I would do away with all that MSP stuff.

phenominal improvement, AK! I will spend some time really studying your changes.

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:

do you think using Gen to build the core button/color output functionality would be of benefit?