#1

I’m wondering if it’s time to cut a 2.0 release of the Teletype firmware? There’s a bunch of new features already baked in or about to be…

  • Telex OPs
  • Aliases
  • PN versions of all the P ops
  • Sub commands

I know these have little to do with the original v2 proposals, and we could just keep incrementing the minor version number (e.g. 1.5, 1.6, etc). But if we did bump the major version I wouldn’t mind making a few minor breaking changes…

  • Get rid of the II op, promote whatever needed it to first class ops.
  • Consider renaming some Ansible ops to deal with name clashes (prefix with an A? e.g. AMP.RESET)
  • Move the F1 help key elsewhere (SysReq?), so that we can trigger scripts with the function keys (maybe even allow for shift F-key to take you to the edit screen for the corresponding script).

Anyway not sure how people feel about it… in some respects it makes little difference to me as I just compile my own firmware anyway.

7 Likes
A user's guide to the wonderful world of teletype ⌨
#2

no idea about version number…

… but +1 to all of your proposals. #3 IMO both great ideas.

thanks again for your hard work!

as someone who doesn’t have the toolchain up and running, would love to see your changes in a release soon!

#3

If we do go for a 2.0, then I’ll start posting some beta firmwares.

#4

I wouldn’t mind a version bump to tidy up (at least in my head) all the new TT things popping around and study them carefully (instead of following a thread and asking myself if i really want to try the new thing before it gets upgraded…)

But one thing i would really like to see from the original V2 proposals is the MIDI ops. I sometimes use my Ansible for Midi CV conversion, and it would be really great to do this inside TT (so that i can use Kria with my grid at the same time!).

Beside, MIDI CC ops would allow to act on the Teletype variables from any MIDI controller !!

1 Like
#5

midi ops would be a dream come true!!

but I wouldn’t expect it too soon (also, it’s #3 on that list). unless one of the dev lords would reeeeallly want it.

of course I hope I’m all wrong…

#6

i think it makes sense to use v2 to introduce breaking changes (and there is one breaking change i would like us to consider - changing ansible / tt remote code to use the same address for all the different modes so that some remote commands could be shared by different modes).

i like the ideas too. not sure about moving F1 functionality though as it’s such a natural association that it would be helpful to beginners especially, but then judging from other threads many people were not even aware of it, so maybe it’s okay to move it to a different key. you can already execute scripts with WIN+number though but yeah, it’d be nice to not have to use a combo for it. and having a combo for jumping to specific script would be awesome.

#7

agreed on v2.0 and i like the feature proposals.

when i get the new features in from the original v2 proposal (oh no, almost a year ago! dang arc build!) we can do a v3 as they’ll be major also.

re: F1, i’m wondering if it’s a sort of legacy assumption at this point-- many users may not even remember the days when F1 meant help? does it mean help in many modern applications these days?

2 Likes
#8

speaking strictly for windows most of the apps do support F1 still, but yeah, the main thing is to have that reference available, how to invoke it is less important.

#9

I’m going to open up a PR for the work I’ve done so far this weekend. I’d like to get that merged in soonish so that any work from others builds on top of it.

Going forwards, I’ll mainly work on my branch and open up PRs at suitable points.

I’ll try and get a ‘Teletype 2.0 beta’ thread opened up on Monday with some hex files for testing, along with a list of the stuff left to do.

Help is usually ⌘-? on Mac, not that anyone uses it.

The big downside to triggering scripts on the F-keys is that it’s easy to do it by accident, it might be that triggering needs to be modifier and F-key. I guess we won’t know until we can try it.

Sorry. I doubt these are going to happen just now.

1 Like
#10

i can see a benefit of not having to use a modifier for triggering though (and if we keep a modifier i’d change it from WIN button to CTRL - i find i always have to first locate WIN and often hit FN instead). with a modifier using F keys doesn’t seem much different from using 1-8, but F keys are easier to locate.

perhaps this is something that could be configurable? selectable modifier, including the option to not have a modifier?

1 Like