The main order that matters in the trigger [t b b b] sequence is that the clear is on the farthest right side while the gFlip is on the farthest left.
I made it refresh at 100 ms. When it was at 50ms, which is the limit of the controller, there were some hangs where the pd patch and controller were out of sync. I think…
The oscilloscope is just sampling 128 bit crushed samples with the refresh rate, but I think it will be possible to increase the sample size and lose some details on the waveforms.
yeah running down at 50ms / 20 fps might start to hiccup. (the controller is around 20ms, but has some jitter, and that will cause a dropped frame). 60ms might work too, also all those graphics messages start to eat CPU I’m sure you noticed.
a tiny envelope (like just a triangle) for knob 2 might be fun too!
I created a realtime oscilloscope abstraction based on the GFX demo.
Argument 1 is scaling (0-63). Argument 2 is offset from top of the screen (0-63). realtimeScope.pd (1.6 KB)
Here is a general use-case for filling the entire screen with the oscilloscope.
The [r~ channel] is receiving from a single master channel output.
this is cool, thanks for posing these little tidbits. this one will come in handy!
I noticed a little bug: if scaling is 64 (as in the picture above), the mod operator inside realtimeScope forces it to 0, and you don’t see anything. so scaling range is only up to 63.
