getting back to 2.0 discussion (will reply in the other thread shortly) - didn’t see any other bugs. i did get the screen only partially refreshing in some cases, but this could be related to when running it under heavy stress. in any case doesn’t seem like a major thing.
@sam - you said you’re planning on releasing 2.0b10 later today? will it include all the IRQ related changes introduced since d059926?
I’ve seen that too. Screen rendering is done in the event loop now, instead of directly from a timer (and given that things inside a timer callback run with a masked timer IRQ, that’s a good thing, screen rendering is sloooow). The downside is that it can glitch out under heavy load.
It’s possible (probably even) that the SPI code is not re-entrant. Given that CV updates and slewing occur in a timer callback, it’s possible that they pre-empt the screen rendering while it’s halfway though the process. Basically, does it occur only when doing CV? Something to look at in 2.1 I guess.
yeah, could give this a try, although i’d be hesitant to make changes to that part of code - this might introduce some latency to CV updates, which would be undesirable if you have slewing enabled, for instance.
so far my thinking is that ideally i’d want to get to the point where timers have higher priority than triggers, and timers are split into 2 different priority groups, system timers (responsible for processing grid/arc/keyboard/module controls/screen refresh/output updates) that would just do their work in their callbacks and wouldn’t need to be masked from the event code, and regular timers that would generate events.
I had been thinking of moving that code over to the cvTImer_callback, really they both belong together. What ever you do, see if you can put them both together, either in a timer callback or in the event queue.
this is another reason to split timers into critical and non critical, i think. CV updates and trigger updates should all be handled by critical timers (or perhaps CV slewing and triggers off should be critical timers and triggers on and setting CVs could be regular timers using events).
My setup, all running stuff:
I had a play today and didn’t encounter any crash. (I’m being more gentle with my TT, using control rate triggers). Amazing stuff! Thank you so much sam for all the effort you put into this!
Display glitches now and then
saving (writing) to usb took longer than expected (me being too impatient I guess as we’re talking maybe 20 secs)
command history seems to iterate through a fixed length array even though no commands are in. not sure if this is intended or not
preset scrolling could be endless too (I had an effect after saving that took me to preset 31, couldn’t reproduce this one sadly, gonna try further)
preset numbers starting from 0 is slightly weird IMHO, not sure how it was before though
anone else having mostly “dfu-programmer: no device present” when executing update_firmware.command the first time when connected? Took a lot of attempts until it worked here, no other action done other than re power cycling module while holding button and re plug usb (at least needed 10 times), all ports tried. might be something local to my machine
I have a scene that makes heavy use of the logic ops:
In my understanding, AND and OR will not be different in this script (probably not, since their logical and bitwise outcomes will be the same when used for triggers, right?). However, since XOR has been deprecated, I will need to replace all instances with NE.
Now that AND and OR were switched to logical instead of bitwise, would it makes sense to keep XOR but alias it to NE? That way, scripts with XOR won’t break, and they’ll be changed over to the logical equivalent just like scripts that already use AND and OR.
O is being counted on each script read, it is set to O.wrap and O.max 43.
I have the command:
IF EQ 0 27: CV 3 N PN 0 Z
So every time O gets to 27 as it counts, the note going out CV three changes. This am, I fired up the Scene, and the CV 3 out wasn’t changing. I could change it manually, but the argument wasn’t working.
I went to manual mode and typed in O a few times to confirm that it was counting, and indeed it was making it’s way up to 43 and looping.
I tried a few more things, but ended up not altering anything else in the Scene. Went back to check on O counting, and it was still counting. I saw 27 roll by and presto: CV 3 started to work! It was like the argument was being blocked from reading the return from O until I saw 27 flash by in the manual mode.
Anyone else ever seen this? Hope my explanation made sense!
I should add that I’ve been confused by the O functionality in the past, and maybe this why…maybe it wasn’t working as it should [scratches chin].
Sorry if this is obvious, but: what is the latest, stabile Teletype firmware that will work with the Telex I and O expanders?
I have been following all the threads with developments and testing, but sort of lost track of where things are at. I do have the expanders, and want to take advantage of them, but do not want to compromise the stability of my setup.
If you absolutely need to use the expanders and cannot wait for the stable 2.0 release, I would use the current beta. 1.4.1 was actually more unstable for me than this beta (as documented somewhere in this 316 message thread hahah). Most importantly in your case, using the II bus with an M script and external triggers was causing pretty quick crashes, even with simple scenes. This was even with the use of the II backpack.
There are still a handful of minor oddities, but I’ll take occasional graphic glitches over hard crashes any day.
Forgive me if this was covered elsewhere, but is it possible to add more available variables? I often run out…
As far as I know, there is only X,Y,Z and then reassignable T, A, B, C, D…but usually those are being used for their given purpose. Is there a technical reason they are limited or is it more of an aesthetics choice? I’d like to have ten available!
Yes. In 1.4.1, I was experiencing crashes when combining these three things:
So, you could use any combination of two of those and theoretically have a stable setup in 1.4.1.
The M Script is, in my opinion, very valuable when using the TXi expander, hence my suggestion to use the beta. One other crash that was fixed recently in 2.0b is that TT 1.4.1 would crash when receiving audio rate input triggers, just in case you were thinking of rapid triggers as a workaround!