#437

Makes sense. There is a delay before I2C and scene init that the changelog indicates is exactly for this reason, but maybe newer ER301 firmware revisions take a little longer to boot and this is no longer sufficient? Possibly you could increase this delay value and see if it improves.

Possibly, but this would be a breaking change to the interface and require changes from O|D and firmware updates on all modules for this to work, so it seems quite difficult to try and coordinate a design change like this. Hopefully just deferring initialization fixes the problem.

Major oops, some of these new ops had documentation written in the Teletype repo but it did not get compiled into the final manual correctly. Very sorry for the confusion, change summary for v3.1.0 is now corrected at the beginning of the manual.

2 Likes
#438

Of course, might be a few days though…

#439

Ok, I tried with 3000ms (was: 1500ms), still not working. Could anyone with a TT/301 combo verify?

#I:
SC.TR.TIME 1 100

#1:
SC.TR.P 1

#440

For posterity: Joe on the O|D forums found that the ER-301 takes ~12 seconds to reliably boot and accept I2C messages. Brian may revisit the issue of accepting I2C messages during boot-up in the future.

1 Like
#441

I think a SCENE.I OP variant which runs the INIT script of the freshly loaded scene would be very powerful for meta-sequencing. EDIT: This is in contrast to SCENE which loads a scene but does not trigger INIT.

It would enable, for example, state machine type compositions where each scene represents a state. INIT would define the entry action for each state.

I guess I’m hoping to attract the interest of one of our perennial Teletype devs as my own insufficient talents won’t bring this across the finish line. The substance of the change seems small compared to SCENE.G but I don’t know much about testing, github, compiling, etc. (and honestly I can’t figure out whether the run_script(&scene_state, INIT_SCRIPT); belongs in the new OP’s function or in tele_scene() or what).

#442

Is the intent to run the init script of a different scene without otherwise loading it? If so this might not be possible because tele_scene (the function to switch scenes, e.g. in the implementation of the SCENE op) overwrites the “live” scene memory with the new scene loaded from flash.

If you just want to run the init script of the current scene you can do this with SCRIPT 10 in recent betas (latest I think is here, change was merged here). SCRIPT 9 runs the metro script, the numbering is chosen to match the F10 / F9 keyboard shortcuts. This op uses run_script_with_exec_state to preserve the current execution state (variable values, loop limit checks, etc.) which is important when starting one script from another to prevent self-referential scenes from crashing the module.

1 Like
#443

Oh I didn’t do a great job of explaining:

SCENE loads a new scene but doesn’t trigger INIT of that scene. I’d like to load a new scene and trigger INIT just like when loading a scene from the menu.

EDIT:
Alternatively I would petition to change the behavior of the existing SCENE OP to run INIT. Would anyone object? If you’ve designed a scene with the intention of loading it from another scene, you also would have no reason to avoid running INIT because you can always just leave it blank. The variable values already carry over between scenes (I believe) and INIT would only change them if you want it to. Heck, the only counter argument I can think of is that it’s a “free scene” using $ 10 but that really is secondary to its intended use (and new enough to not be a breaking change for many existing scripts).

2 Likes
#444

I’m just getting into TT but my two cents are like this:

I like SCENE. It would let you expand a simple set of scripts into something mutated as the global variables carry over.

I see SCENE.G and I appreciate it - although I don’t have a grid yet.

If there was a similar SCENE.I it would make sense - given the presence of SCENE.G.

However, SCENE and SCENE.G are similar in that they both OMIT a running their paired script. So then implementing a SCENE.I for consistency means that it would load the scene but in addition it WOULD load $ 10 (init) which is backwards from how SCENE.G works with the GRID script… And if we made a SCENE.I would we then not need something to load a scene and in addition skip running the G AND the I scripts? Perhaps there is a more elegant solution.

As a new user having SCENE also load $ 10 makes more sense to me. The init script is paired with the scene for a reason…

Just to float an idea:
SCENE ($)- loads scene, and init and grid
SCENE.I ($.I) loads scene while skipping init
SCENE.G ($.G) loads scene while skipping just grid
SCENE.GI ($.GI) loads scene while skipping both init and grid.
Logical, clean. However, may break old scripts calling SCENE.

#445

SCENE 2; SCRIPT 10 totally works to call the new scene’s init :face_with_hand_over_mouth:

Now what I desire is an OP for saving pattern data :joy:

2 Likes
#446

Excellent, this seems ideal to me - you can script whichever behavior you want!

As in, an op that saves the current pattern data to the current scene’s flash slot? I’m quite interested in this self-restructuring autophagic Turing metamachine it sounds like you’re trying to build, though it makes me a little anxious about the finite number of write cycles the flash memory can take.

#447

Speaking of pattern data, I had once put in the request for adding the ability to instantly recall the already saved pattern data without having to reload the scene. It would make a great way to sort of get back to the song after randomizing a bunch. Not sure if that’s still on the docket but I would love that ability.

#448

Why not just use SCENE to reload the current scene? Unless you are live coding and don’t want to revert the scripts…

Perhaps more interesting would be an OP which loads only pattern data from a specified scene. Or maybe even a specified range of that data!

Yep! And I hadn’t paused to consider the possible stress on the flash. I’m not sure a flash write can be executed without a brief system hiccup anyway.

My application would include things like using Scene 1 as a Turing Machine (synth parlance, not computing) which records drum patterns to the pattern data. Leaving Scene 1 for Scene 2 would currently destroy those sequences.

#449

I suppose it might be helpful because when you reload the scene it updates more than is necessarily wanted at the time? I tend to shift my pattern start and end points a lot when performing, and also change variables. I believe when you reload a scene, it loads up those start and end points that were initially saved and it also reinitializes my variables. It’s not that big of a deal but as a technique, pattern recall would fit right into my workflow.

In previous versions of my scene, I used the Teletype metro as my master clock and I’d get little timing hiccups when switching or reloading scenes, but that could be chalked up to bad programming really. Nowadays, I trigger the teletype from outside sources and never get timing hiccups.

edit* But I love your idea about loading pattern data from specified sources. That would make it way more interesting!

Go Teletype!

1 Like
#450

Everything else you mention is a barrier, to be sure, but using the SCENE OP definitely doesn’t reinitialize variables.

1 Like
#451

Ah, good to know! Thanks!

#452

anyone else having problems flashing current 3.1?? (on a first edition teletype)

symptoms:

TT boots and shows its usb-saving screen, and then crashes. no screen, leds TR2+TR3 on, nothing happens…

this is with pre-compiled binaries from the 3.1 release. also tried compiling 3.1 myself with the same result. going back to 3.0, everything seems to be working as expected.

(disconnected a power hungry module in the case, should be plenty of headroom either way)

edit: ha! so after confirming a usb save operation with the button (even without actually inserting a thumb drive), 3.1 works as expected and across power cycles.

(would be happy to test a possible fix, but since it’s no issue after pressing the button…)

#453

do you remember what it said on the screen when it happened? this sounds like the bug fix that we added to prevent teletype from accidentally erasing everything in flash memory. if the part of the code that does that gets called somehow, it should show a warning message and ask you to confirm.

this should never happen during normal operation but it does need to reinitialize flash after installing new firmware, and if you don’t, flash will contain garbage which tt then tries to execute and freezes.

1 Like
#454

omg. thats it! I was so sure it meant for usb saving/recalling on startup :see_no_evil:

but: I don’t understand this feature yet. it also says: “do not press otherwise”, which implies I have a choice. but if I don’t confirm it stays in this limbus state, unless I confirm it on any future startup and the new firmware is flashed. don’t get me wrong, I don’t see much benefit in putting any sweat in this either.

3.0 flashes and boots into normal operation so I was just a bit confused and worried I broke something by flashing it, since I had previously added modifications :sweat_smile:

many thanks!!

1 Like
#455

i agree the message could be clarified - it should explain that you should only need to press the button if you’re seeing the message after flashing a new firmware.

#456

This post got me thinking about some possible ops and mods for doing transformations of a whole pattern at once. Would love to hear other ideas, syntax thoughts, whether these would be worthwhile as ops or are just as easily scripted, other thoughts! Each would of course need P. and PN. variants.

P.SHUF           -- shuffle the cells in a pattern 
P.REV            -- reverse a pattern
P.LROT / P.RROT  -- rotate the pattern cells backward / left or forward / right

Also possibly interesting could be mods providing higher-order functions that let you run some code on each pattern cell, populating I and/or J variables with each pattern element, like a specialized loop mod. For instance, the map and scan (like fold, but keeping the intermediate values) functions:

P.MAP: * I 2     double each cell in the pattern. equivalent:
                 L P.START P.END: P I * P I 2
P.SCAN: + I J    replace the pattern with its cumulative sum. equivalent:
                 L 1 P.L: P I + P - I 1 P I
6 Likes