#164

Sorry, not quite sure what I’m looking at… is it that the text has extra stuff on the end? Could you have a look at an earlier scene, it looks like it might contain parts of the description from one of those. If that’s so, then I think I’ve thought what it might be.

Yes, most likely any line that has a II command on it will disappear.

Upload the tt0X.txt files if you want me to delve deeper.

#165

Yes, exactly. So I have “Triangle Mountain”, then in slot 1, “Randomse Mountain”…

As you say, I’m assuming the II commands are getting dropped, which makes sense. Has anyone got 2.0 versions of the standard scenes?

The other good news is that the USB r/w seems much more reliable, and I’ve got it to work with USB keys that wouldn’t work on the 1.0/1.1 releases.

#166

OK, loads fine (aside from the description pages) once the scripts have been fixed to remove II.

#167

On the case now.

There is also an issue with descriptions being corrupted when saved.

New version coming up soon. Best not to use beta 6 if you haven’t flashed it.

#168

Beta 7 in the first post.

Fixed the saving / loading glitches occurring in scene descriptions.

(Found and) fixed another bug whereby sometimes consecutive scenes would not be loaded.

Please when testing, can you check that scenes are being saved properly.

1 Like
#169

Following this post as a new teletype user (although I can’t power it at the moment.) Just curious about flashing. Do you have to flash the teletype when installing the new releases? What is the difference between flashing/installing vs. just installing?

#170

Looks like it fixed the description issue, and seems to be saving scenes ok. I am getting a crash with one of the scenes I have in my collection. I’ll send it on via PM.

#171

Thanks to @GoneCaving and the script he provided, I’ve figured out another bug…

Basically, if a line of a script has an error, it’s imported as a blank line, which causes issues elsewhere.

The fix should be straightforward. I can stop blank lines crashing in the general case (even though they shouldn’t be allowed), and then we can try to skip broken lines on import rather than insert blank ones.

1 Like
#172

Any chance there could be some indication that the script has a problem when loading? Bonus if it says which scene/script. Course, I guess this only occurs when the script is edited outside of TT.

#173

I’ve been following along, eating some popcorn over in the corner. Ready to dive into this. What is the recommended way to absorb all of the changes? Flip through the different beta release change logs, or have new commands been compiled somewhere?

Thanks!

#174

I’d love to, but I’m not sure if I have the time (or the willpower), the USB memory stick code is hard work.

edit: thinking about this, we could display that an error occurred on screen, and then write the details of that to a text file on the USB stick. But in my opinion that should only be done after someone volunteers to do the rewrites I’ve suggested above. Trying to cram even more functionality in without fixing the underlying issues will just cause bigger problems down the line.

I think the first post contains everything you need to know. I’m hoping to post a new beta with the last of the USB loading niggles worked out later today, so I’d wait for that before flashing.

Once that’s done, it will be time to sort some new docs out.

2 Likes
#175

Thank you. I’m excited to use the new tools.

#176

Beta 8 uploaded in the first post.

Fixes an issue whereby scripts with incorrect commands were being inserted as blank lines (which caused crashing). Thanks again to @GoneCaving.

And also another bug whereby the same broken commands were causing subsequent valid commands to not be imported correctly.

1 Like
#177

Fair enough. I don’t think it’s big enough an issue to hold up the rest of the work in any case. I’m assuming that this changset


would be the place to start?

#178

Yes. Best to try to understand the entire tele_usb_disk function. But otherwise, you can see the 2 failure states, a parse fail, or a validate fail. Currently they’re are printed out on the serial port.

I still think trying to stick extra functionality in, without fixing the fundamentals first, makes for more bugs and more headache down the road. I can’t tell you how many times I’ve changed something innocuous and had the entire memory stick code fail, or caused the keyboard code to fail after a memory stick is used, or it would only work once a reboot, or that only the first script would import properly, and on and on.

1 Like
#179

Sorry for not replying sooner. In this context flashing and installing can be used interchangeably. We flash the firmware onto the teletype to install it, there is no other way to install it.

Did you get a USB A-A cable with your teletype? You’ll need one to flash the firmware. Further docs are here.

#180

Thanks @sam,

I do have an A to A cable. Thanks for answering my question. The 1.4 firmware file does not have a flash.sh folder in it like the new beta folders do so I was curious about the differences.

#181

flash.sh is the same as update_firmware.command, it’s got more or less the same contents, but it’s designed to be run from the command line instead of a double click from the Finder.

(A little developer aside, I added a make release command to the Makefile to build the zip file, I figured it would be something I needed to do often…)

Out of interest have many people tried beta 8 yet?

1 Like
#182

I’m dying to try it, sadly exams have been too rough last weeks. Should have time this weekend finally…

Thank you so much for your hard work sam!

1 Like
#183

Anyone else running beta 8 yet?

I think there are only 2 or 3 things left to look at before it’s releasable. (There are some other things I’d like to do, but they might need to wait for my next burst of coding energy.)

The thing left are:

  • Meadowphysics vs Ansible ops
  • Documentation
  • (and maybe) Telex aliases

Right, Meadowphysics has the following ops available to use:

  • MP.PRESET
  • MP.RESET
  • MP.SYNC
  • MP.MUTE
  • MP.UNMUTE
  • MP.FREEZE
  • MP.UNFREEZE
  • MP.STOP

Whereas Ansible has the following ops (when in Meadowphysics mode):

  • MP.PRE
  • MP.RES
  • MP.OFF
  • MP.SCALE
  • MP.PERIOD

This seems a bit confusing to me, especially if you’ve got an Ansible and a Meadowphysics in your rack. But I’m not quite sure what to do about it. My one idea at the moment is to prefix all the Ansible ops with A, e.g. AMP.PRE.

Any other ideas? Or is it just not that important?

Next up documentation. My intention is to try to create some sort of structured data file to hold the documentation (see here for what I’m thinking).

The question is, do we just want the output to be a something akin to a cheatsheet, with a very short description of each op. Or we would we rather have a proper manual with detailed info and maybe some examples for each op (in addition to the cheatsheet).

I should point out, I’m not planning on writing all the content myself! Instead I’m planning on writing some Python code to translate the datafile to Markdown and HTML (and possibly Latex), as well as to check for ops with missing documentation.

Please shout out if you’d like to help with the docs, no coding experience required. I can take care of cutting and pasting into the datafile.

Lastly, @bpcmusic, do you want to create any aliases for the Telex ops? Don’t worry if it’s too much to deal with in the next few weeks, there’s no reason why they can’t be done in 2.1 or later.

5 Likes