#339

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

1 Like
#340

I love this community - that is all :slight_smile:

4 Likes
#341

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?

#342

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?

Telex: Teletype expanders
#343

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

Telex: Teletype expanders
#344

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

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

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.

Telex: Teletype expanders
#345

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?

1 Like
#346

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

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.

#347

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!

:grinning:

#348

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.

1 Like
#350

i like the proposed solution as well - i really like the new TAB functionality - for whatever reason i found the previous system really confusing. and i like the idea of having dedicated keys for direct access. not sure about using F11/F12 keys though - i’d keep them for something else we might need in the future.

#351

It was more for people with 3rd party keyboards that might not have a num lock or print screen key.

Anyway, it’s an easy change to make. Will do it this evening.

Been thinking about this. I’d rather not do the whole 191ms if you can shave things down. But I think a little delay (50ms or so) might be prudent before running the I script.

1 Like
#352

ah didn’t think of that, makes sense.

1 Like
#353

I do think some delay is reasonable. :slight_smile:

Let me see what I can do to optimize on my end.

Thx!

b

#354

Shortcuts added for live mode and pattern mode. It works well.

Nice and easy to do too:

2 Likes
#355

I’ve had a look at the code, and can’t see anything that would cause the issues your facing (that doesn’t mean it didn’t happen though!).

Basically unless I can reproduce a bug it’s really hard to fix.

With this command, if Z isn’t changing, then CV 3 won’t change either. Is it possible that was the issue instead? Similarly the value in the pattern (at PN 0 Z) might be the same, again you won’t see a change on CV 3. Also if Z is below 0 or above 63 it will always read the first or last value in a pattern (and CV 3 won’t change).

#356

Release candidate 1 out now, download in the first post.

Changes since beta 10:

  • More OP documentation, big thanks to @bpcmusic, @GoneCaving and @tambouri for their contributions

  • ME.PRESET and ME.RESET renamed to ME.PRE and ME.RES

  • XOR added as an alias to NE

  • Support for the newest TXo OPs

  • New keybindings: NUM LOCK to jump to the pattern editor, PRINT SCREEN to jump to live mode. The help short cut has been moved to alt-? (don’t forget to press shift too).

Known issues:

  • Tables in the PDF can be hard to read. Sorry about this, it probably won’t be fixed until after 2.0 is out. But if it makes you feel better I find it really annoying too (which makes it likely that I’ll want to fix it).

  • Screen glitches. They’re safe to ignore, we know why they’re happening (CV updates interrupt screen updates). Should hopefully be fixed in 2.1 by @scanner_darkly

The only things I’ve got left to do are to add some documentation on the new features in 2.0 and update the builtin help text.

Given that work on 2.1 has already started, I think we’re looking at major bug fixes only now.

11 Likes
Does your teletype stop responding after an hour or two?
#357

Moving TX startup details to the expander thread.

#358

Hello all. I’ve got a new version to upload but I can’t seem to edit the first post anymore…

A bit of Googling points me towards:

@tehn, any chance for an increase on the time limit so that I can make one (last) edit for rc2.

Teletype 2.0 documentation
#359

Apologies for hijacking the thread, but if I wanted to build a firmware that handled more than 8 scripts, is it as simple as a modification to SCRIPT_COUNT in state.h? Has anyone tried this?