Teletype 2.0 beta (release candidate 2 released 13th July 2017)

First the bad news, I’ve limited the M op to setting the fastest metro to 25ms (equiv. to 16th notes at 600bpm…)

But… I’ve added a M! op to allow setting the metro at unsupported speeds down to 2ms!

:sunglasses:

(sorry for the terrible video quality)


I’ve just glanced over at my Teletype and Ansible, they’ve been sitting there for the last 50 mins still running the same script at M 25. I’d forgotten about it…

3 Likes

Following up on this… I’m going to remove XOR. It has an identical truth table to NE when used for boolean logic.

1 Like

agreed.

furthermore i’d say we should simply leave out bitwise ops for now.

1 Like

Still running… 5.5 hours. Need to flash a firmware though.

Ansible was directly connected to the Teletype, no other devices on the i2c bus.

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?

1 Like

Beta 10 released. Download in first post.

Changes since beta 9:

  • breaking: remove unused Meadowphysics ops: MP.SYNC, MP.MUTE, MP.UNMUTE, MP.FREEZE, MP.UNFREEZE (these no longer work with MP 2.0)
  • breaking: rename Ansible Meadowphysics ops to start with ME, and make the names consistent with those used by Meadowphysics (names are now: ME.PRESET, ME.RESET, ME.STOP, ME.SCALE, ME.PERIOD
  • breaking: remove op XOR
  • new: M limited to setting the metronome speed to 25ms, added M! to allow setting the metronome at unsupported speeds as low as 2ms (save first, though I haven’t crashed it yet…)
  • improved: script recursion goes far and wide now
  • improved: AND and OR use boolean logic now, and are not bitwise

This version uses the latest version of libavr32 (with all the changes @scanner_darkly), please abuse the I2C.

PDF docs included in the zip, thanks to @GoneCaving and @tambouri for their contributions. Still a lot of OPs need documenting though.

Developers, given the focus is now documentation, I have merged all the changes from my 2.0 branch into the docs branch. Please use that instead.


Unless something major comes up soon, this will be the last beta for a week or 2 (school holidays are about to start).

Assuming all goes well, expect to see “release candidate 1” at the end of May.

Two more questions to leave you with. Do we want to increase the number of delayed commands from 8? And likewise stacked commands (also 8). 16 for each?

4 Likes

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.

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.

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.

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.

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

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

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

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.

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

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:

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.

Thank you for the suggestion.

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

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:

  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!