#352

@tehn I did not witness it. They just weren’t there anymore. Will back up!
Actually, it might be a good thing to start from scratch

#353

I was hesitant to post, as I don’t have many details. But, when I updated to 3.0 I noticed something similar. The first time I powered the TT on I was greeted with the stock/ demo scenes, but they all disappeared after a few power cycles. It’s hard to say just when as I might not have noticed immediately.

(At the time, I just assumed it was user error somehow and decided to keep a lookout here for similar reports.)

edit: for what it’s worth, I just reflashed 3.0 and the stock scenes have persisted through multiple power cycles.

1 Like
#354

I’ve recently updated to 3.0, the default scenes are there and haven’t saved any of mine yet since I’m still in the explore/study stage but I’ll keep an eye on it.

1 Like
#355

thanks for testing! when it happened that time do you remember if you saved any scenes at any point, or was it still just loaded with the release scenes?

@yoyosandshoes and @Justmat one more question, do you remember using calibration ops at any point before it happened?

1 Like
#356

I don’t think that I had saved anything yet, it was fairly soon after I updated. For sure a no on the calibration ops.

1 Like
#357

I haven’t used calibration ops ever (unless I know them as something else?)

1 Like
#358

that would be IN.CAL.MIN, IN.CAL.MAX, PARAM.CAL.MIN and PARAM.CAL.MAX

i’m doing some testing as well, so far not able to reproduce it, will go over that code tomorrow as well to see if i can spot anything.

1 Like
#359

so far i’m unable to reproduce the issue. if anybody else ran into this at some point - could you post as many details as you remember?

i’m also not seeing anything in the code itself. perhaps other developers could take a look and see anything i’m missing in the following analysis?

here is what we know:

  • this happened with the official 3.0 release with the default scenes included
  • at some point (after several power cycles) all scenes are blanked out.

this implies that at some point flash was written to. f is local to flash.c so the only way it could’ve been done would be through the functions exposed in flash.c. i’ve looked at all of the places where these functions are called.

1st possibility: flash_prepare gets called each time a module is powered, and if f.fresh is not 0x22 it will blank out all of the scenes. the only way for this to happen should be flashing tt with a non release firmware (the official release would already have it set to 0x22, otherwise the default scenes would also get overwritten on the 1st power up, which we know didn’t happen). flash_prepare is not called anywhere else.

2nd possibility: f.fresh somehow gets overwritten when something else gets updated (last mode being the primary candidate as it gets updated whenever a user navigates to a different page). i’ve double checked all of the places where flash is written to and all flashc_memcpy calls are done with proper sizeof. also if this was the case then we would see this happening a lot more. i’ve also tried saving from every mode to see if i can reproduce - no luck.

3rd possibility: something calls fresh_write (which writes an individual scene) with a blank scene looping over all available scene slots. the only place other than flash_prepare that does this is when it reads from USB - but it only does it if it finds a valid scene file. you would have to use a USB stick with files specifically named for reading for each scene for this to happen - not very likely.

flash_prepare seems to be the most likely candidate, which means it’s back to f.fresh getting corrupted somehow. but i don’t see how it could possibly get overwritten - it only gets updated in flash_prepare. so it would be either it getting corrupted by itself at some point or getting overwritten when something else is updated. could there be some tricky possible issues due to using flashc_memcpy with structures? padding not being accounted for somehow? but sizeof would take that into account…

#360

I am fairly certain that when I installed the official 3.0 release, I did not get any default scenes - just had empties. I had just assumed it didn’t include any. Not sure if that’s helpful or applicable here or not.

I have not had any trouble with losing any since then.

2 Likes
#361

@scanner_darkly @EqualTemperament I’m working on trying to get your two teletype/grid integration scenes (morphing faders and base controller) to work and I am having trouble getting the 301 to recognize commands from teletype. I’m on Teletype 3.0.0 firmware (plus a few keyboard fixes) and 0.3.25 on the ER-301 (revision 10 board, did not have to solder i2c pins). I am using a 3-pin to 3-pin cable to connect between an i2c backpack on the teletype and the 301 (no twists, like the wiki says). I have enabled teletype integration and am using the first address (0xBO) in the device settings on the 301.

On a clean scene, I can not get the 301 to recognize the commands SC.CV 1 V 5 or SC.TR.P 1 when the port is set to 1 for either device in the 301. By not recognize, I mean that you don’t see the oscilloscope present on the ER-301 screen respond to the changes. Any ideas? About to try a 3x2 -> 3x2 ribbon cable I have to see if it happens to be the cable.

#362

you have to set the address to 0xB1 or 0x31 (doesn’t matter which). details here: https://forum.orthogonaldevices.com/t/i2c-communication-with-monome-teletype/743/466

#363

Ah awesome, thanks, the Wiki’s info about addresses here might not be up to date. It mentions 0xB0 for ports 1-100. http://wiki.orthogonaldevices.com/index.php/ER-301/Teletype_Integration#Configuring_the_ER-301

#364

Changing to 0xB1 works perfect, thank you!

1 Like
#365

@scanner_darkly @yoyosandshoes @tehn I’m still running 3.0 RC5 on my Teletype - not yet upgraded to the release version - and all my scripts are backed up… Is there some testing I can do here that might help? A specific version to upgrade to, specific steps to take, things to check / note along the way etc.?

1 Like
#366

thanks for the offer - this would be really helpful! the 2 cases we know of happened with the release version, so probably best to test with that as there is a small chance it was something introduced since RC5. it’s hard to say what to test for though as it’s not clear at which point it happened, so maybe just use it as you normally would and keep an eye on the scenes, and if you are able to reproduce it see if you can remember what you did just before it happened - this would help narrow it down.

#367

No worries! I’ve upgraded to 3.0.0, and so far everything is fine; Teletype boots as TELETYPE 3.0.0 22D6CE8, default scripts were present (but script 08, previously “ORCA TELETYPE VERSION” has been replaced by a script named named “TEST”).

I replaced all scripts with my backed-up scripts. I’ve power-cycled a few times, started up with & without the keyboard connected, loaded different scripts: all scripts are still there. I’ll let you know if it all goes pear-shaped.

1 Like
#368

Just noticed this happened with mine that’s on the latest release. All saved scenes blank.
In a makenoise powered skiff. Didn’t have anything plugged in or out.
I’d updated a few weeks ago and things were fine. Just noticed it today and hadn’t used it in the last week or so.
Sorry not more details.

#369

do you remember if you saved any scenes at any point before it happened, or was it just the default scenes that come with it?

#370

Yes, I saved a couple scenes (3 or 4) before it happened. I’ll reinstall a pay a bit of attention when turning it on and off.

1 Like
#371

thanks for the additional info!

at this point i can’t tell from the code itself how it could possibly happen, and we don’t have solid steps to reproduce to help with the investigation. obviously, this is very concerning. here is what i propose to do:

  • i will update the code so that the flag that indicates that all scenes should be blanked out will get reset whenever flash is updated

  • @tehn’s idea - i’ll add a confirmation so that if it somehow decides to overwrite scenes it will ask you to confirm first. you’ll never have to confirm in normal use but if something somehow triggers this at least you’ll get a chance to cancel.

3 Likes