1.3.6 firmware: about o_c HOT 10 OPEN

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

from o_c.

yes right off the release page. I'll try it on another device here today using the exact same hex.

from o_c.

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

from o_c.

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.

from o_c.

Ok, we will leave it at that. Sounds like an edge case

from o_c.

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.

from o_c.

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

from o_c.

Good to know. Never a dull moment with Arduino compilers

from o_c.

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

from o_c.

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.

from o_c.