Teletype 3.+ feature requests and discussion

teletype

#170

related thread: (Teletype) USB Disk Mode Interface

not home right now so can’t check, but looking at the code SCENE shouldn’t reset grid controls. if it does i’ll definitely fix it to be consistent with how it works for other things. you know, it never occurred to me to use SCENE as a way to go beyond 10 scripts! it can make scene sharing more complicated but the benefit makes it worth it. and this could be a good way to implement a more complex grid controller for, say, er-301 where you could have a set of controls shared by all scenes, and each scene can customize how those controls are used.


#171

I did a small test and this is what I found. I’m running the most recent build that @alphacactus posted in this thread. Teletype 3.0.0 267A22F

Scene 6
I:
G.BTN 1 0 0 8 8 0 3 1
SCENE 7

Scene 7
1:
IF EQ 1 G.BTN.V 1: TR.P 1

If scene 6 is loaded from the keyboard (ESC, [] to Scene 6, ENTER), then the button displays but SCENE 7 is not loaded. This is the same behavior if scene 6 is loaded from the grid ops controller.

If after loading scene 6, the INIT script is re-run by pressing F10, then it proceeds to scene 7. The grid ops button remains intact and triggers script 1 in scene 7. Same is true if you run INIT manually from grid integration.

Finally if you change it so that SCENE is called from a numbered trigger script instead of INIT:
Scene 6
I:
G.BTN 1 0 0 8 8 0 3 1
SCRIPT 1

1:
SCENE 7

then calling scene 6 from the keyboard or grid integration proceeds to scene 7 with the button intact, and firing scene 7 script 1.

I’m not sure if it’s expected behavior that calling a SCENE op from INIT doesn’t do anything or not… I mean it does but only if the script is run manually and not as part of scene load.

But yeah, using this technique, you could theoretically have at least 9 scripts for set up kinds of things, leaving all the scripts in a called scene open for reacting to events. Possibly you could get even more scenes of set up but you’d have to trigger the 2nd set up scene’s INIT manually with an F key or grid integration, I think, since a scene called with an OP won’t run INIT automatically.

I hadn’t thought of but do really like your use case where a single scene sets up a consistent set of grid objects, then you can call many possible other scenes to have the familiar objects do different things. :slight_smile:

EDIT: Kind of a caution here though - I think in the final config, I have blocked myself from ever editing Script 6 which may be why it doesn’t load the scene when INIT is run at scene load. Probably need to read the parameter knob to evaluate whether you want to edit or proceed to the next script.


#172

this sounds like a bug to me (although perhaps there are some specific reasons for why SCENE shouldn’t work from the init script).

re: the init script not executed when SCENE is used - it sorta makes sense. if you have a multi scene set up your script will likely switch between different scenes multiple times, so you probably wouldn’t want them reinitialized each time. on the other hand, it would be useful to have a script that gets called each time a scene is called with SCENE. so yeah, maybe a separate op that gives you this option?

not being able to edit - that’s an interesting side effect ) and yeah maybe it’s the reason for how it works now. i guess you could just use SCENE to load it in this scenario. if we change SCENE behaviour then a different shortcut could be added for scene loading (like shift-enter) indicating you don’t want to execute the init script after it’s loaded.


#173

I like the idea of shift+enter to load a scene without executing init. I know there are lots of people who would like to see more/phantom scripts and/or timeline (me included). It seems to me like that’s going to be a pretty major enhancement, and I’m not sure I’ve seen any devs jumping up and down to take it on. :slight_smile:

Using this SCENE technique, plus the new local variables opens up a lot now. This + some improvements to the USB storage mechanism to make it more dynamic without a computer, I think, would open up a ton. I read through the linked thread on USB Disk Mode interface and had to smack my forehead and say “derp!” when I realized the keyboard and storage media couldn’t be connected at the same time. But the proposed menu system looks really good!

Is there already a list somewhere already of what’s preserved vs. reset to default when a scene is called using the SCENE op? Or if not would it be worth me spending some time to document it? This is not a comprehensive list but I’m just thinking about things like:

  • grid ops objects
  • global variables inc. things like (O, DRUNK, etc.)
  • local variables
  • CV.SLEW and CV.OFF (inc. things like TO, JF, SC)
  • TR.TIME
  • pattern data itself and P.START, P.END, P.L, P.N

#174

yeah, i think adding a section on this to documentation would be great and would help to ensure it’s consistent. i’ll try to find the time to document it when i get a chance.


#175

not sure if this was resolved, but flash_read(called when by the SCENE op) would write the grid ops saved by flash_write with the unpack_grid and pack_grid calls. I’m not entirely sure what unpack_grid and pack_grid do, but this may be the cause of this behavior.


#176

Calling a scene with the SCENE op does not reset grid ops objects, which is the expected behavior. Sorry if my wording was confusing.


#177

when you define grid controls (with G.BTN / G.FDR and their variations) that definition is not stored to flash. you have to set them up in the init script. what is stored to flash is grid button states and fader values. this is so that if you, say, use grid buttons as a trigger sequencer, then your sequences will be stored when you store the scene to flash or usb (unpack_grid and pack_grid serialize it so that it takes the least amount of space).

now, if you have some grid controls defined and you load another scene from flash it will reinitialize all controls and hide them. but when SCENE op is used it will not do this, which sounds like exactly the behaviour we want (as it will allow creating grid scripts that could span multiple scenes).