O_C
O_C copied to clipboard
mxmxmx
1.3.6 firmware:
Display goes crazy when CV is used to rotate scale mask. This behavior happens on all channels, but as far as I can tell it only happens when the input is assigned to scale mask (using the same CV inputs for transposition or octave does not create the issue.) Video of problem here:
https://photos.app.goo.gl/Ph1TgTgqSzJ5J8oAA
Reverting to 1.3.4 eliminates the issue
is that the hex file from the releases page? or something else?
either way, this https://github.com/mxmxmx/O_C seems to be running stable here (using "teensyduino" 1.35), modulating both cv aux channels set to "mask" or "scl#".
yes right off the release page. I'll try it on another device here today using the exact same hex.
Cant seem to replicate on a different device. I got some more details on the conditions:
- a scale is selected
- triggered (not continuous) mode is on
- source is set to external cv (might happen with internal sequences, haven't tested that)
- cv aux is set to "mask"
- voltage is received on the cv aux
Hm. AFAIK so far no one's been able to give a reproduceable scenario. I've seen the glitchy display only once, and that was running totally experimental code that had 1001 other issues.
All I have are vague theories like
- some{how|times} the external interrupts on the TRx mess up the timing, which borks the display.
- Some displays aren't tolerating the (way) out of spec driving at 30MHz. IIRC the datasheet claims 10 or so.
All are pretty thin and not really actionable.
Hm. AFAIK so far no one's been able to give a reproduceable scenario. I've seen the glitchy display only once, and that was running totally experimental code that had 1001 other issues.
All I have are vague theories like
- some{how|times} the external interrupts on the TRx mess up the timing, which borks the display.
- Some displays aren't tolerating the (way) out of spec driving at 30MHz. IIRC the datasheet claims 10 or so.
All are pretty thin and not really actionable.
I have had the glitch screen issue many times to be honest. After doing power down and up again it is gone.
@altitude909 , thanks for trying. that's pretty much the settings i was using, on both channels. i get the glitch when i compile the code with some recent version of teensyduino; it's ok when using 1.35
generally speaking, re "glitches", i think what's pretty clear is that gcc versions > 4.8 for whatever reason produce binaries that are less robust. i've never figured out why that is; except that the display-glitches tend to be a function of lots-of-stuff-going-on in the interrupt, like updating the quantizer a lot (which happens when rotating the scale).
Yeah, newer versions do seem to exacerbate it. FWIW it was still on 1.35 where I saw it, but just the once.
Intentionally (because it would never happen otherwise :smile:) exceeding the time available for the main ISR processing tends to manifest as a different result: UI bogs down and eventually stops. I did quite a few tests with audio rate clocks into TR1-4 simultaneously at some point. There are some bugs I've found reusing the weegfx code but those would be immediately obvious.
I have a few other vague inklings but given the lack of debugger and without a reliable test scenario to poke at it, it's just a time sink.
So, FWIW... fix/display_glitch
This commit seems to suppress the symptom (*) of glitching display when built with 1.8.12 + Teensy 1.51, at least on the test bench. It still builds with 1.8.1 (saved some space) and the glitch can be seen with a 'scope there too if you know what to look for, but seldom on-screen. Why the behaviour is so different between 4.8 and 5.4 compilers is a different mystery.
(*) The actual issue is apps exceeding their processing timeslot, it just manifests way differently than I assumed (yeah, I know). So there might be side effects (i.e. it's not really been tested properly) and some more safeguards required.