#473

I’ve just been experimenting with multi-Scene Teletype programs using

SCENE.G x; $ 10

to load a Scene and run its INIT script.

This works fine - and I can use the Grid to pass values between Scenes by encoding them into the Grid state. However, it got me thinking that it would be extremely useful to have a similar op SCENE.P, which would load a Scene without changing the existing Pattern contents. Is this even a possibility with a firmware change?

1 Like
#474

this seems like a useful suggestion - having different scenes being able to work with the same data set could open some interesting possibilities.

the question is - how to combine the 2. what if you want to load a scene while preserving both the grid state and the pattern data? this becomes even more complex if we want to support loading a scene while preserving current variable values.

1 Like
#475

I suppose the simplest solution would be:
SCENE - loads Scene with nothing preserved.
SCENE.G - loads Scene with Grid, Patterns, Variables preserved. (Or some other suffix). If Variables or Pattern values are defined in the Scene being loaded, they would write over those being passed - so it shouldn’t affect a Scene that is not meant to be loaded this way - or am I missing something?

#476

@polycorn I added FADER.SCALE x y z, FADER.CAL.MIN x, FADER.CAL.MAX x and equivalent FB aliases. Essentially mimics the behavior of the same OPs for PARAM and IN.

My PR was merged so should be in v3.2 when it’s released: https://github.com/monome/teletype/pull/198

6 Likes
#477

this will happen regardless of how you load a scene. the SCENE.# variations are just to bypass loading grid state or pattern data from flash.

what i meant was - sometimes you want to load a scene without initializing grid data, so you use SCENE.G. sometimes you want pattern data to be preserved, so you use SCENE.P. what if you want both to be preserved? then we either need SCENE.GP or SCENE.PG op or some new op where you can specify what to initialize.

maybe something like:

SCENE.# scene var pattern grid

where var, pattern and grid parameters are set to 1 if you want to initialize them, 0 otherwise.

2 Likes
#478

Awesome! That will save me a precious line here and there! Thank you (all?) so much for working on this thing. Cheers! Poly

1 Like
#479

Yes, that’s what I was trying to say - it happens regardless. I hadn’t considered that there are initialized states to grid and pattern (ie a Scene assumes all Pattern values are zero). But I think we are on the same page, I’m just not explaining my thinking very well on very little sleep.

I like this solultion, 3 parameters to the alternative SCENE op, Grid Pattern Var set to 0 or 1.

The only problem with that is some folk may be using SCENE.G already? Is it too messy to have SCENE, SCENE.G and SCENE.X 1 1 1 all existing?

(Apologies for not using the code styling, I can’t for the life of me remember how to do it!).

I do hope there is a way it can be introduced. Having a Grid layout from which you can trigger entire Scenes is pretty powerful as is, but if Variables and Pattern data persisted too, I can imagine some very sophisticated setups would be possible!

1 Like
#480

yeah sorry, what i said wasn’t correct - SCENE.G and variations would be to bypass loading grid state or pattern data from flash (not initialize them with default values as i previously said).

i think it makes sense to have different variations of the op, in addition to SCENE.G, particularly SCENE.P being a useful op.

1 Like
#481

No problem - I read it as bypassing initializing grid and bypassing loading the new scene’s pattern data.

I suppose SCENE.G, SCENE.P, SCENE.V, SCENE.GPV, SCENE.GP, SCENE.GV, SCENE.PV would cover all possibilities… Could there be a use-case for passing the Metro state independently? Or any other variable?

The advantage of using SCENE.X Grid Pattern Var would be that you could do something like SCENE.X 1 RND 1 1 to randomly decide whether to keep the current Pattern data or not! :crazy_face:

#482

oh i see what you mean. i would limit it to SCENE.G, SCENE.P, SCENE.V and SCENE.# (might need a better name for this one).

i don’t think metro state/rate is changed when you load a different scene?

1 Like
#483

Ah, where SCENE.# is the op with the three parameters? Perfect!

You’re right. I was trying to think if there was a special variable that one might want to persist without every other variable being passed to the new Scene. An edge-case.

Coming at it from the opposite angle, would it be technically possible to grab some kinds of data from a Scene without loading it? For example, to get the value of PN 0 6 from Scene 14.

#484

yeah, it would be technically possible. i don’t know whether reading/writing individual values is a good idea (as flash does have some limit on number of reads/writes), but loading/saving full pattern banks could be useful.

2 Likes
#485

Hi, I’m feeling a bit lost. Could someone point me in the right direction for the latest teletype beta? The one posted at the top of the page (E27F640) sounds like it’s pre 3.1.0 and I recall reading somewhere that there is a beta that fixes the help screen lines wrapping around and allows triggering of the metro script.
Is there a central database of all the betas by date?

#486

I’ve just added the latest builds to this post, which seemed like the best option for a one-stop-shop. A new Teletype release should be out soon.

No, but the edit history of the above thread can maybe sort of act like this if other firmware devs and I update it.

3 Likes
#487

Thank you for that! Now I can get back to music making :smile:

#488

i’ve also updated the links in the firmware guide to point to the latest release threads.

1 Like
#489

Not many talked about ops for w/, please allow me have some suggestions that I’m not sure that could be possible or not.

Currently there is a WS.REC X for controlling the record behavior, but in absolute manner, -1, 0 & 1. I am wondering if it can be something like WS.THAT X or WS.RECV X while X is a -5 to +5 voltage value to make it like sending a voltage to THAT (or THIS) by an invisible patch cord. Or even a CV.WS (14 bit) op so that it can be integrated most of the Hardware ops to w/.

2 Likes
#490

The problem with adding ops for W/ is that the firmware for W/ isn’t open source, so it needs the Whimsical Raps folk to make the corresponding changes at that end.

1 Like
#491

started a new thread: Teletype 3.2+ feature requests and discussions
@tehn - should we lock this one?

1 Like
#492