gpvillamil

I have built a step sequencer that is more or less working, except for a big problem. Each step is a number box, and the number boxes are very unresponsive when the patch is running.

My suspicion is that this is due to the method I am using to indicate the active step - first, changing the bgcolor of all the number boxes to black (using an uzi) and then changing the bgcolor of the active box to red.

I tried sticking a defer after the messages that change the bgcolor, and while responsiveness improved, the highlighting stopped working.

How can I make the patch stay responsive while running, and also have the highlighting work? Running the subpatch on its own seems to work well.

Patch and subpatches are attached - sequencer test.maxpat is the main patch.

Changing the "length" number boxes changes the length of the sequence, and grays out the inactive number boxes.

Turning on the beat clock and enabling the layer starts the sequencer, and you should see a red highlight moving along.

number-boxes-in-patch-are-non-responsive

You don't need to send the background colour to every number box, only to the currently active and last active, one on and the other off, perhaps use [bucket]. If you do this you will stop a lot of redrawing.

If you want to be even more efficient you could utilise the transparency and layering of the objects you use so that you're only redrawing one object per step. Line up your [number]s or a [matrixctrl] set to "dialmode 1" (excellent for step sequencers!) and use a [multislider] to indicate the current step. I haven't explained it very well so here's an example. I hope it helps.

That's great, thank you! Very easy to use.

I'm thinking maybe of sticking a jit.cellblock over the multislider...

Well, I've changed the patch to use a multislider to move the highlight.

However, when I embed more than one instance of the bpatcher, it still becomes unresponsive to user input. Response to number and checkbox input is sporadic at best.

The overall patch works fine, and seems to be generating events correctly. It is just that sometimes it takes multiple tries to get it to respond to entering a number or clicking a checkbox.

Overall CPU utilization is tiny - less than 2% - so I suspect something is happening with how Max handles I/O? I tried switching overdrive on and off.

However, when I embed more than one instance of the bpatcher, it still becomes unresponsive to user input. Response to number and checkbox input is sporadic at best. 

In your first patch you had the [bpatcher]s layered a bit messily. Either set the size and offset properly or enable the "clickthrough" function so you can reach what is behind them.

I re-arranged the bpatchers to not overlap, and now they're chugging along nicely. (Probably what was wrong in the first place).

Number boxes in patch are non-responsive