#252

AFAIK the Just Type stuff is the same as it was in earlier firmware versions. All the existing OPs are still there.

If you didn’t know, the code required in the Teletype codebase to make Just Type work is trivial and doesn’t do much apart from send messages to Just Friends do things. All the big things happen on the Just Friends.

1 Like
#254

Hi @sam, i was out this wknd, so late reply.

Re: doc formatting. Echoing @Leverkusen, I think the tables in the pdf aren’t the most stunning visually, but they seem fully functional.

I’m unsure of the formatting abilities of Pandoc, but it feels (as you mentioned in another comment) that left aligned tables might be a simple fix for the pdf. Additionally, I’d be curious about additional thinner horizontal lines between rows. I think this is part of what is making html tables a bit more quickly legible (for me)

All of this said, it seems more about getting a doc together which holds all of this info, and both seem to be doing a good job at that. If I’m following you correctly, we could then pull the vital info into a design program to make a more easily formatted cheat sheet.

I’d still be interested in helping w/ the docs and cheat sheet

#255

You can write your own Latex template, though some of the table stuff is hard coded. It’s a job for someone that really knows their Latex (or is willing to learn), and is willing to commit to keeping it working. As far as I’m concerned, if someone volunteers to do it, then there opinion matters of above all else (so if your mission is Comic Sans everywhere, now is the time to pipe up).

I could probably do it, but there is only so much time…

Basically yes. The content is separate from the design. For now I think concentrating on getting the content sorted is most important. I’ll try and open up a thread today or tomorrow, I need to get a discussion going on the audio rate trigger issues first though.

I will admit that the way Pandoc works, by having a default that’s really easy to use, but allowing for custom templates with all the extra effort entailed, really appeals. It makes it easy for me to punt most of the design stuff. My experience is that if open up the discussion too much on design it will generate too much feedback and comment, and then there is a danger of nothing happening. I’d rather deliver something imperfect.

1 Like
#256

I agree, and I think the docs you posted last communicate all the pertinent info clearly. So unless we find that Latex guru who loves comic sans :wink:, the current incarnation seems to work nicely

1 Like
#257

I’ve fixed this now. The fix will be in beta 9.

2 Likes
#258

Beta 9 released: The Audio Rate Edition

Firmware available in the first post

Changes since beta 8.

  • Audio rate triggers no longer crash the system (including when the triggered script sends i2c messages). Your Teletype may become unresponsive with audio rate triggers, just slow them down or unpatch the cable to regain control.
  • Increased system responsiveness under audio rate triggers
  • PARAM will still update when on the pattern editor screen
  • Long OP names don’t crash the system when missing parameters

Also from @bpcmusic

  • TELEX Aliases: TO.TR.P for TO.TR.PULSE (plus all sub-commands) and TI.PRM for TI.PARAM (plus all sub-commands)
  • TELEX initialization commands: TO.TR.INIT n, TO.CV.INIT n, TO.INIT x, TI.PARAM.INIT n, TI.IN.INIT n, and TI.INIT x

Next up

High tempo. long running metro scripts can still lead to problems (I think). Although I’ve been trying to get something to break with a Teletype and an Ansible and I can’t.

If someone can knock up a script that does, that would be fab.

In theory, it’s not the Teletype crashing, but rather the keyboard and screen handling code being starved on time on the CPU. In essence you can’t turn the metro off.

Otherwise, it will be time to start declaring release candidates soon.

edit: have managed to crash the Teletype/Ansible with crazy metro i2c stuff, interestingly I think it might be Ansible that crashed, and thus took out the Teletype (via the i2c code), if only I could reproduce it more reliably. I’m wondering if the fixes I made to Teletype may also fix some things on Ansible.

edit 2:

Here we go, put this in your metro

L 1 100: STATE 9

Make it go fast with M 10. Wait a few seconds. Crash (if you’ve got a serial port you can see that the event queue starts overflowing indefinitely)

What’s interesting is that if you have a reset switch on your Teletype, you can reboot just the Teletype. If you do, it works fine… until you try to communicate with any i2c command (even to non-existent devices).

4 Likes
#259

@sam - just did a couple of crazy audio-rate tests

Ran 15 minutes of an 8kHz square wave banging a trigger input that sent out TO.TR.P. UI locked up - but restored itself admirably after unplugging the cable. Totally stable.

Rebooted and got evil. Set up triggers 1-4 for reading and writing: CV n TI.PRM n. Plugged four oscillators on square waves into them. Ramped up nicely and found some points where the UI was less responsive, but usable with the updates to the CV values looking butter-smooth. Then I put all 4 oscillators at 8kHz. Expected UI lock. Left it a few minutes, then unplugged. Everything is back to normal.

Massive stability improvement for ridiculous patching!!

BTW: Also confirmed that the TELEX aliases and INIT commands are in and performing nicely. :wink:

wow.

5 Likes
#260

Now if only the changes to fix Teletype didn’t break Ansible…

Could you try some TI or TO ops in the metro script at crazy speeds too?

I’m trying to figure out if the metro crashes are due to Ansible crashing or the metro locking out the UI.

#261

This is amazing!!!

I’m running the following M script at 10ms with 1 x TXo and 1 x TXi on the bus:

L 1 4: TO.TR.P I
L 1 4: TO.CV I V RAND 10
L 1 4: CV I TI.PRM I

Been going for 30 minutes. UI is totally responsive. Param knobs update the CV outputs of the TT responsively and feel butter-smooth. The TXo keeps chugging away with wildly fast triggers (dialed down the pulse time to 1ms) and flickering CV lights.

I have a feeling this could run all day. :slight_smile:

2 Likes
#262

I’d been doing that with some of my testing on the internal outputs. That slightly flickering light was a good feeling.

#263

It just keeps plugging.

Though, at these speeds, I’m starting to get worried about the fabric of the universe.

vortex.jpg1000×750 304 KB

Might need to turn it off soon… :wink:

5 Likes
#264

Have managed to fix the bug in the Ansilbe firmware.

I can now run this script at M 10, the UI get’s incredible unresponsive. But it is possible by repeatedly mashing on the keys to get to the live prompt and type a sensible value for M in.

edit: finally managed to crash Ansible, but it took an awful lot of abuse.

3 Likes
Does your teletype stop responding after an hour or two?
#265

Just faced what looks like a bug when using the LOOP PRE in order to trigger a SCENE, was there some modification with that PRE’s behavior i might not be aware of?

The patch was working fine in 1.4.1 but seems broken on 2.0 beta 8 and 9 (no crashes though).

#266

No changes that I’m aware of.

Fabulous, that will definitely make it easier for me to help / fix it.

Ansible update:

Ansible i2c is definitely improved, but it is the weak link now.

For whomsoever comes after me… it might be worth considering i2c bus recovery over and above finding each and every bug in Ansible/Trilogy/etc. If the i2c goes down it easily crashes the Teletype.

#267

I managed to isolate the problem:

1 (externally triggered)
SCRIPT 2
SCRIPT 4

2
L 0 5: SCRIPT 3

3
(empty)

4
TR.PULSE 1 (this one is just for visual feedback)

Issue : SCRIPT 4 isn’t triggered.

So i think that LOOP is breaking the chain of action preventing to get back to SCRIPT 1 in order to finish its code (here triggering SCRIPT 4).

@sam Hope this helps.

1 Like
#268

If you change

L 0 5: SCRIPT 3

to:

L 0 4: SCRIPT 3

does script 4 trigger?

edit: checked it myself, and it does work. Basically, you’re running up against the new script loop protection. I can probably make some tweaks to how it works inside a loop… will write up the options tomorrow.

#270

Yep you are right it works with that patch but in the complete one it won’t work until i decrease it to L 0 2 (a lot of thing is going on in that patch, with a lot of SCRIPT triggering, i can’t tell if it is related).

BTW i also tried to replace the LOOP with something like that and reached hit the same wall:

2
SCRIPT 3
SCRIPT 3
SCRIPT 3
SCRIPT 3
SCRIPT 3
SCRIPT 3

It would be awesome if the number of values could be increased to something like 8 or 9 or at least 6 as the number of lines in a script :innocent:

#271

Such a simple change…

Basically the new script loop detection works, not by trying to detect loops (if you try to do that you run into the halting problem), but instead by limiting how many times any script can run from a single trigger (or metro, or delayed command, etc). The reason for doing this is to stop the infinite loop. But because scripts can recurse into each other there is a danger of a stack overflow, thus the limit of only 8ish SCRIPT calls.

(as aside it is possible to remove the danger of the stack overflow by using a ‘trampoline function’, but that would require far more work)

Anyway when I wrote that code I was focusing purely on the danger of the stack overflow which comes about from nesting scripts (e.g. script 1 calls script 2, script 2 calls script 3, etc). But the way the code works is overly simplistic and all it does in effect is count how many times you run any script. So the solution is to decrease the number after the script finishes. That way the limit is on how deep the nesting is, not how many you run.

tl;dr: you can use SCRIPT a lot now, the limit is how deep the nesting goes, not how many scripts you run.

The code will be in the next beta, which may in fact be the first release candidate.

4 Likes
#272

Thank you very much for that readjustment (and the hard work btw).

1 Like
#273

Quoting myself…

Anyone wish to comment?

This is one of the last things to resolve…