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

[Leverkusen]

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.

[sam]

Hi all. Sorry for the lack of timely responses, I’m a bit busy with school holidays. I’ll be able to reply to everyone from the middle of next week.

[sam]

Hi all, back from my family holiday. Let’s go…

Display glitches now and then

Known issue… sorry! It’s a bit too complicated to explain. It’s nothing to worry about and it’s been done for a good reason, but it probably won’t fixed properly till 2.1 (courtesy of @scanner_darkly).

saving (writing) to usb took longer than expected (me being too impatient I guess as we’re talking maybe 20 secs)

As far as I know that’s the same speed it was before.

command history seems to iterate through a fixed length array even though no commands are in. not sure if this is intended or not

Whoops, I’ll try to get that fixed. If it hasn’t been by the next beta, remind me please!

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)

It will be related to loading preset 31 from USB. Known issue, not sure if I’ve got time to fix it (the USB disk code is pretty hairy!).

I’m not sure how I feel about the loop around for preset navigation… thoughts anyone else?

preset numbers starting from 0 is slightly weird IMHO, not sure how it was before though

Ah. The age old battle between engineers (0 indexing) and mathematicians (1 indexing). I think it’s always been 0. If it hasn’t I’ll change it.

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

Having flashed my Teletype more times than I’d care for… most important is to make sure the USB A-A cable is disconnected when powering off your modular. If it’s connected before you power off, the Teletype won’t fully turn off (as it draws power over the USB cable).

would it makes sense to keep XOR but alias it to NE?

Yes it is a good idea. Even if it’s only in there for a few versions before being removed.

I might see if I can add a II op that does nothing to aid transition for that too. (It might not be possible, so don’t get your hopes up everyone!)

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

I haven’t got the brain space for this just now, I’m trying to get back into the swing of things again. Could you prod me to look at again in a few days (if I haven’t already)?

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.

If you ever learnt a bit of code, you could probably add as many as you could think up names for… (although the computer scientist feels compelled to note that variables are the source of many bugs… anytime you can do something without them, do!)

Otherwise… yes use A to D. In fact IMO we should entirely stop using A to D to refer to the TR outputs and all docs should be changed to reflect that. New hardware ditches it too.

If anyone wants to volunteer to rewrite the Teletype studies series to reflect 2.0 and the current consensus for the best way to do things please shout out!

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.

I’m not surprised by this sadly. Could you try on 1.4 (or 1.4.1) and tell me if that has the same behaviour?

---

Phew.

[sam]

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’ve added XOR as an additional alias to NE (along with !=). Will be in the next drop.

I might see if I can add a II op that does nothing to aid transition for that too. (It might not be possible, so don’t get your hopes up everyone!)

I couldn’t get this to work easily, sorry all!

[Geremy]

Can we keep a bitwise and so that we can store multiple parameters to the same pattern? Or have more patterns please?

[sam]

It’s probably a bit too late in the 2.0 release schedule to make a change like that. It’s possible that specific bitwise versions could be added in the future.

But it would probably be better to try and address the root cause instead. Either more patterns (if that’s the consensus) or different tools to address the same problems.

[sam]

The plan is for the next release to be release candidate 1.

I have a few small bug fixes left to do. Otherwise it’s just docs (and the builtin help text) left.

However… as it’s a major version number change, I would like to have a final look at the Ansible ops and see if any name changes are warranted, as it stands they are:

• KR.PRE
• KR.PAT
• KR.SCALE
• KR.PERIOD
• KR.POS
• KR.L.ST
• KR.L.LEN
• KR.RES
• ME.PRESET
• ME.RESET
• ME.STOP
• ME.SCALE
• ME.PERIOD
• LV.PRE
• LV.RES
• LV.POS
• LV.L.ST
• LV.L.LEN
• LV.L.DIR
• LV.CV
• CY.PRE
• CY.RES
• CY.POS
• CY.REV
• CY.CV
• MID.SHIFT
• MID.SLEW
• ARP.STY
• ARP.HLD
• ARP.RPT
• ARP.GT
• ARP.DIV
• ARP.RES
• ARP.SHIFT
• ARP.SLEW
• ARP.FIL
• ARP.ROT
• ARP.ER

As part of 2.0, the previous MP.* ops were renamed to ME.* so as to avoid name clashes with Meadowphysics. The names were also lengthened (e.g. MP.PRE became ME.PRESET).

This has made the ME ops a bit inconsistent with the other Ansible ops.

This is the last opportunity to make the names consistent with each other, what should we do? Go back to the shortened names (e.g. PRE instead of PRESET)? Or change all the others?

---

edit: bumping this back to the top…

[emenel]

Agreed. Consistent and short is good.

[sam]

Okay, I’ll change ME.PRESET and ME.RESET to ME.PRE and ME.RES.

command history seems to iterate through a fixed length array even though no commands are in. not sure if this is intended or not

(I had an effect after saving that took me to preset 31, couldn’t reproduce this one sadly, gonna try further)

I’ve fixed both of these too.

[tehn]

Okay, I’ll change ME.PRESET and ME.RESET to ME.PRE and ME.RES.

agreed. consistency is best.

[sam]

I’m just working my way through the Ansible ops documentation…

Rename ME.OFF to ME.STOP?

(originally it was MP.OFF to avoid the clash with MP.STOP, but OFF feels like offset to me)

(whoops, already made that change!!!)

[Dogma]

I love this community - that is all

[Leverkusen]

I am still not a fan of the new switching between edit, live and tracker page. I constantly mess up my patterns when I just want to switch between edit and live page to alter M or a TR.TIME while programming a script.

Maybe I have no style but I can’t see how switching through three states is a good idea. The number of needed key presses constantly changes depending where you are. The good thing with a keyboard is that this is not neccessary since it has a lot of keys.

Can we have the old behaviour back, please?

[bpcmusic]

TT 2.0 Startup Observation

I’ve noticed that the TT starts up so quickly now that any i2c commands in the init script are not received by the TELEX expanders. I validated this by putting some commands into an init script and comparing the response of Ansible to the TXo. My findings:

• Ansible will respond to a CV 5 V 10 command placed at the beginning of the I script

• The TXo does not respond to a TO.TR.P 1 command at the beginning of the I script

• Adding 190ms delay (and below) before the TO.TR.P 1 command to the and the TXo still does nothing

• Adding 191ms delay (or more) before the TO.TR.P 1 command to the TXo allows the expander to initialize, receive and perform the command

I’ve looked at my startup code in the expander. It is pretty lean - save 4ms of accumulated delay that I could maybe remove.

@sam - would it be too much to request putting in at least 191ms of startup delay before running the I script in order to give the expanders (and perhaps other i2c devices) time to startup and settle?

[tehn]

seems your startup code could be optimized?

https://forum.pjrc.com/threads/30588-Teensy-quot-Boot-quot-time

paul says 5ms, so perhaps we could figure out how to get your i2c registering earlier in your setup process

[bpcmusic]

seems your startup code could be optimized?

Quite possibly. I know of at least 4ms I should be able to trim.

The expanders used to beat the Teletype to the ready … then @sam came along. Damn him!!!

---

Right now, startup is clean and logical. I don’t do much outside of reading the jumper setting, setup the DAC, initializing some classes, and turning on i2c. A quick profiling of this shows that my init function after reading the three i2c jumpers takes less than 1ms. Hmm…

I have a feeling the delay is from some static, large lookup tables being copied to dynamic memory when the app is constituted (before the app initializes). I’ll have to dig into it to see if there is anything that can be done.

[sam]

I used to get so lost with the old setup.

How about a different solution, hopefully better…

I’ll move the help key from PRINT SCREEN to alt-? (this is the same key used by OSX, sort of).

The I can add NUM LOCK as a shortcut for pattern editing, and PRINT SCREEN as a shortcut for live mode. (I will also add F11 and F12 as backups for those on other keyboards). TAB will stay as it is.

That way along the top of the keyboard we have:

• run scripts with F1 - F10
• edit scripts with alt-F1 to alt-F10
• jump to pattern mode with PRINT SCREEN
• jump to live mode with NUM LOCK

Thoughts?

[sam]

The expanders used to beat the Teletype to the ready … then @sam came along. Damn him!!!

Yeah I fixed the USB memory stick code, so no startup delay required anymore.

I have a feeling the delay is from some static, large lookup tables being copied to dynamic memory when the app is constituted (before the app initializes). I’ll have to dig into it to see if there is anything that can be done.

Is this data that needs read access?

You can use objdump (from your toolchain) to check which sections are loaded into RAM and which are kept as RO in ROM, there are some other tricks to list the largest variables and where they are too.

<Insert caveat about Harvard Architectures>

Start a new thread (or PM me) if you want some help deep diving.

[Leverkusen]

run scripts with F1 - F10

edit scripts with alt-F1 to alt-F10

jump to pattern mode with PRINT SCREEN

jump to live mode with NUM LOCK

I liked the old style as it needed just one key to switch between what I understood as the woe main pages plus the tracker key. Seems Easy to me.

But this proposal seems to be like a logically consistent solution and might be a reasonable compromise.

Would be great if it could be implemented!

[chrisharrisx]

Just so that @Leverkusen doesn’t feel like a lone voice in the wilderness – I’d be very happy if this could be implemented as well. PRINT SCREEN and NUM LOCK seems like a great solution.