Display screen glitches - too fast to handle?

Hi all!

Almost finished my first patch and tweaking the display screen, the patch is loosely inspired by the Yamaha Tenori-On bounce mode. Bouncing balls drop from a random height and sound when they hit the floor. The patch is based on a diatonic major scale with counters running in palindrome mode.

Display works great at lower tempos, but as soon as I get about halfway on the dial it starts glitching out. I am wondering if I am asking too much of the display (the counters are moving very fast) or if there is something I can do within the patch to stop the glitching? (If I remove all animation patch works perfectly with no audio glitches)

Any thoughts much appreciated!

Here is video: Boucing Balls Display Test - YouTube

From the C & G graphics demo. “The internal update rate is around 20 frames per second, so you shouldn’t send commands (or groups of commands e.g. to draw a frame) faster than 50 ms, it will only eat CPU.”

So try to call graphics updates less somehow. No idea how to do that from watching the video. Looks great though!

how are you buffering the frames?

Ah ha - missed that from the C&G graphics demo in all my excitement. Yes, commands are MUCH faster than 50 ms and I don’t think it will possible to reduce, think I will go back to text-only interface, an entertaining rabbit hole I went down nonetheless. Thank you for the heads up!

I am triggering each frame from the counter object, 1 triggers position 1 etc (then clearing each frame triggered by tempo). If that answers your question?

How would I buffer a frame?

Many thanks

Can you not just filter out the screen update commands as the eye can’t see that fast?

E.g. this only allow a 250ms bang through every 2 seconds. Probably better ways to do this appropriate to your code or maybe not possible at all!

sshot

oh wow this is a great idea! :clap: