My requests for new firmware are:
- More lines per script
- More varibles
My requests for new firmware are:
There is a long discussion of this very topic here: (Teletype) expanding scripts: length and amount with very interesting insights from both sides (also some neat tricks, tips, and workarounds).
So, I’ve been spending more time with my IME Stillson Hammer mk2 again lately after neglecting it when I got a Grid + Ansible (Kria). I’m not really sure if these fit more into TT op requests or Ansible/Kria feature requests. I could see them being implemented in either place, but I figured that you’re all much better at TT than I am, so maybe you have some suggestions. I know some of these things might be possible with grid ops (eg: I’ve seen @scanner_darkly do some random generated stuff, iirc).
A couple things from the SH2 that I’d love to be able to do in Kria, either directly in Kria or via TT, are:
More clock/step selection options: So TT now has the ability via KR.CLK to advance a step on a channel in Kria, but it’d be great to be able to have other directional modes accessible. Forward, backwards, pingpong, random and drunken/brownian. Some of these could probably be reasonably easy to script simply if KR.CLK had a second argument where you could specify how many steps to advance and/or supporting negative clock values.
Random pattern generation: I enjoy being able to randomly generate cv, gate, etc values on the SH2. It’s great for live improv stuff. I know I can easily just mash buttons on my grid, but somehow that’s not as interesting, possibly because it’s slower AND feels less random (humans aren’t good at true random).
in the mean time I’d check out
KR.POS! In combination with
KR.LEN, you can really get super inventive with how to address steps of Kria. It definitely takes more thought (and script lines) than a backwards clock, but all of what you said are possible today.
I’m happy to help with snippets of scripts to accomplish this too, if you’d like.
How did I miss that?! Thanks!
You may wanna check the developments in Ansible Kria Feature Requests!
Would it be feasible for Teletype to automatically poll and pass through FB to SC.CV, without needing to script it? E.g. my default scene looks like this:
I: L 1 16: SC.CV.SLEW I 25 M 25 M: L 1 16: SC.CV I FB I
It’d be nice to just issue “
FB.THRU 1” to take care of it, and then still have the metronome available (and two precious lines in
I, for those who use
I more than I do).
it wouldn’t fit the teletype model very well, since it’s based on discrete events, not continuous processing. doable, but several things would need to be considered:
so in general while using metro script for this might not be ideal it does give you more flexibility in terms of how exactly it’s done. personally, i think a second metro script would achieve this better while also supporting many other use cases. but that’s a bigger discussion…
tt devs - as @tehn suggested, let’s release what we’ve added since 3.0 as 3.1 version.
nope, all good on my end
KR.CUE from me. Would also like to maybe add
KR.DIR for the new direction modes, and any other Ansible remote ops that are quick to add since these require merges to 3 different repos. I won’t be able to work on this for a couple days but will try to PR everything by the end of the week.
submitted my PR for
SCENE.G - this is the only change i have for teletype.
Please make sure the support for all the keyboard type is included in 3.1: it really made a huge difference in my use/experience. (And thank you for developing/addressing that in the first place!)
I believe this was merged shortly after the last release.
Despite hardware upgrades, I have been having serious problems with tuning on teletype (see discussion here: (Re)calibrating ansible CV voltage output). Could a way of calibrating the CV outputs be added? I was thinking of an op that scaled (rather than just offset) the output of each jack and that could be saved to flash.
hi simon— (apologies for the delay on email, i’ve just gotten back in)
i’m going to run some tests on the new and old PCBs here as a baseline. i’m wondering if the (old) assembly house swapped in some poor tolerance passives.
but as a workaround i’m wondering if it’s worth pursuing some sort of manual tuning table.
Thanks! Would be great to know if there is something else wrong with the hardware.
How hard do you think it would be to add a manual tuning table to the firmware of the teletype and ansible? I think it would need to be a table because I’ve tried putting the CV through a VCA and tuning each octave, but the non-linearities are troublesome after 3 octaves or so. (Also, does anyone have any guides for setting up the toolchain for compiling the firmware on the mac?)
I think this would not be too difficult, the tricky bit is figuring out how to load it. If you don’t mind recompiling firmware you can of course do it that way. Probably need a way to import the table from USB disk somehow now that both Teletype and Ansible support that.
I’m on Windows and found the easiest way to be to use this Docker image, but that relies on having Docker set up which can be a bit of a chore. You might also glean enough information from the Dockerfile to install stuff manually, the fiddliest part probably being getting the avr32 cross compiler but I think Atmel provides releases for all platforms. This thread might also have some useful info.
I would love teletype to always count from 0, like in patterns. So ins + out would be 0-3, scripts and trigger ins 0-7. Would make code more elegant, and cleaner.
As much as I relate from a coding perspective, it would render quite a disconnect with the labelling on the panel. Put another way, I think i’d find having a 0-indexed panel quite strange…