#309

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.

#310

perhaps CV and screen updates should also use app_pause and app_resume… i’ll give this a try. i wonder if this explains CV outputs not getting updated when i gave the timer interrupts lower priority.

#311

Alternatively CV updates could go into the event queue too? Given how well the UI holds it’s responsiveness (it’s purely event queue now) it might be worth a go.

#312

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.

#313

FYI trigger durations run via the event code.

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.

2 Likes
#314

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

Does your teletype stop responding after an hour or two?
#315

Late to the party… massively sorry sam!

My setup, all running stuff:
TT
Ansible
TXo
TXi
ES

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!

General observations:

  • 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
#316

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.

#317

I’m running the latest Teletype beta (10?).

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].

#318

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.

Any advice will be very much appreciated!

@bpcmusic @sam @tehn ? :slight_smile:

#319

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.

#320

Thank you for the suggestion.

So is avoiding the M scripts a good way to limit crashes at this point?

#321

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!

#322

Yes. In 1.4.1, I was experiencing crashes when combining these three things:

  1. M Script
  2. External Triggers
  3. II Bus

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!

#323

i think the number of variables was limited to keep TT more accessible. one workaround is to use patterns & the PN command to store, update & recall values.

1 Like
#324

How are you using the A-D variables ? Those seem like an easy 4 to free up if you aren’t doing something interesting w/ your triggers (I was rarely doing much w/ these and have mostly switched to using TR 1-4)

to add onto @shellfritsch 's point about using PN commands while this takes up a little more space in your script a bonus is that you can see the current value of your variable in the pattern mode

#325

So can I still use Trigger outputs by substituting 1-4 in place of A-D, and that won’t interfere with what is going on at the CV 1-4 outputs? If I could freely use those four, that would probably be enough to keep me from marching in the streets for more variables.

#326

the only complication would be if you navigate between scenes using A-D for triggers and new ones where you are utilizing the A-D for other purposes and perhaps have C assigned to a value that isn’t 3 (its default assignment). In this case you’d either want to revise your old scripts to use TR 1-4 or reset variables A-D in your init script which in the 2.0 software you could do w/ a single line like:

A 1; B 2; C 3; D 4

per original documentation http://monome.org/docs/modular/teletype/

A-D are assigned 1-4 by default (as a convenience for TR labeling, but TR can be addressed with simply 1-4). All may be overwritten and used freely.

new units actually just say TR 1-4, which seems to encourage this open ended variable assignment

image.png1024×683 139 KB

2 Likes
#327

Ah, this is great. Thanks for the info…now I nearly have my wished-for ten variables!

1 Like
#328

I am experiencing inconsistencies with pulse length.

TR.PULSE 2 with a TR.TIME 2 10 gives pulses with phasing shifts in pulse lengths up to zero pulse length.