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…
I’d love a zero-indexed panel… right now, I’m rocking the DEVICE.FLIP teletype to keep cables away from the screen and have an upside down 4 indexed panel
I dont get it. This is a computer, the user know it, why hide it?
But you’re right: it’s exactly the stuff that’s printed on the front panel that’s counted from 1, which from a coding point of view is totally arbitrary.
Is there a timeout/max iteration for the W (while) loops? I encountered some strange behavior in the latest beta. I’m not sure if it was there previously.
Teletype will terminate while loops at 10,000 iterations, you could recompile the firmware with a different (16-bit) value, but I think like many decisions in the firmware this is probably a constraint imposed to prevent locking up the module. Really everything happening in all scripts is fighting for time in the same event loop, so this kind of limitation is generally necessary to keep things acting like scripts are independent and so on. I do really like the idea of letting inputs be triggered on rising/falling/either edge though, seems like a tidier solution to this kind of problem.
So approximately how long would that be in actual time. I mean I’m looking at gates on the order of 4 beats @ 110 bpm…
And so if the max is 10000 iterations, shouldn’t I be able to list multiple W statements per script like:
W STATE 1: TR 1 1 W STATE 1: TR 1 1 TR 1 0
In order to achieve 20000 iterations? I tried that, it doesn’t seem to work
It’s basically instant, quick enough to not impact timing of other scripts and delayed events and stuff. Would probably need to set up a scope to get the exact timing. It’s also a limit for the whole script/execution context – if the iteration limit is exceeded it will just break out of any while loop it encounters after at most one iteration, continuing to the next line. Consider:
I 0; J 0; X 0; Y 0; Z 0 W < I 15000: I + I 1 W < J 15000: J + J 1 X I; Y J; Z + I J
Which when executed results in X = 10000, Y = 1. You can set these loop bounds to other values but Z will be at most 10001.
OK then…I mean I can setup an M script and poll IN, but it’s quite a bit less elegant. I know we have been talking about implementing the negative edge triggering for a while, but I guess there really isn’t much interest aside from myself.
This is me registering interest in falling edge triggering of scripts.
I had no idea about the
W loop limitation, and now I need to go back and edit some of my old suggestions…
teletype.hex (573.5 KB)
SCRIPT.POL s p # set script s (1-8) to fire on polarity p # 1 - rising edge, 2 - falling edge, 3 - both SCRIPT.POL s # get polarity of script s (1 - 8) # 0 when script index is out of bounds $.POL s p # aliases for above $.POL s
Polarity of each script input is indicated in LIVE mode with the mutes icon - if the falling edge is active, the next pixel over for the corresponding trigger will be dimly lit as well, so if rising and falling edge triggers are on for all inputs this will look like two continuous rows of pixels. Hopefully that’s not too hard to see, seemed like some visual indication was necessary and this seemed to sort of make sense conceptually.