-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.3.6 firmware: #98
Comments
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:
|
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
All are pretty thin and not really actionable. |
Ok, we will leave it at that. Sounds like an edge case |
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). |
Good to know. Never a dull moment with Arduino compilers |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: