It does in the relatively recent update CLOCK mode.

ooooh. this seems like it could be a real bug. thanks for pointing that out, i’ll check it.

1 Like

Ah I now noticed that you had posted about using the SyncLab add-on over on the operator forum. Is that required for practical use of Op-1 clock?
Now
Seeing as mode 5 of the vanilla Oplab does this:

Output CV2: modular sync.
4 pulses per quarter note.
connect to sync input on eurorack modules and sequencers that use this format.

No cv/gate reslly then in addition to this, just the Teenage Engineering PO and start/stop for the remaining 2 outs.

(I actually sold my Oplab, still holding on to the OP-1).

If CV.SLEW is set, what do I get when reading CV mid-slew?

reading CV during mid-slew will give you the target value, where the CV is slewing to. there’s currently no way to read a mid-slew position.

That’s good, that’s what I was hoping would be the answer.

another firmware v2 idea:

tracker.act

[0/1] show tracker view

adding this parameter to the ā€œIā€ script allows you to auto-load tracker view on scene boot. tracker view is great for visual feedback and i think this could be very handy during performance if you don’t have a keyboard connected.

I’d also appreciate SONG.FINISH and GODDAMN.JUST.CONCENTRATE …

Look! A squirrel!

2 Likes

i like this idea. it however introduces some problematic behavior-- ie, if you had tracker.act in a metro and it would prevent you from ever getting back into the editor.

perhaps a better solution is for TT to remember what screen you were on when shutting down and go there upon bootup?

Yes to TT remembering ā€œlast screensā€!

ahh good point.

yeah!
is it possible to have TT remember what screen you were last on after loading a new scene? i’m switching between multiple scenes in a live performance and would like for the tracker display to remain active.

I’m seeing odd behavior from my TT PARAM knob.
I’m trying to create scripts using it to generate a simple variable 0-100. That’s all fine. I’m using the INIT script to test and hitting WIN I to repeat the argument each time I move the knob to a new position…
All straigtforward, right?
Except sometimes it is behaving as expected and other times not. Sometimes it gets stuck on a value. Hard reset fixes it, mostly…
Is this a known issue? (I did search before posting…)

ah-- i’m going to need a bit more info on the test context. is it not working specifically when doing the hotkey, or does it fail on normal init?

on some screens (tracker, for instance) the param knob may be blocked and rerouted to the interface.

if there is a very specific circumstance for reproducibility, let me know with close specifics and i’ll try to replicate it, or at least identify a potential bug.

In this instance I have simply been moving back and forth between edit and live mode, tweeking code and then typing variables in live mode to see values after adjusting param knob and then hitting WIN I. It hasn’t failed on start up, as far as I can recall, hard reset seems to wake it up, but something else seems to be putting it to sleep.
That’s it. No tracker screens.
I’m working towards a fairly complex (for my tired old brain) scene right now so I will continue to monitor and make notes.

Script pecking order.
The scene I’m working on right now has variables which interact. Thus far the interaction is only in one direction and there are no loops. But the timing of the calculations is critical. X must be established before Y and Z can be, as they are dependent upon X.
What I’m wondering is, with simultaneous triggering, is there a pecking order for scripts to be executed? Should I be sure to calculate X with script 1 if scripts 2 & 3 need to know X?
If I have all 3 asking for the value of X, I suspect chaos might ensue… so I’m thinking of having one script dedicated to establishing X… should it be script 1?

this is new territory. i take it that you are triggering many inputs with the same trigger using a mult?

i’ll need to do some testing to confirm, but i’d expect the scripts to be executed in order-- ie, 1,2,3,4… if they all get the same trigger. if this is in fact not the case, it may be very difficult to hack the code to ensure execution order-- this is a bit of an electrical race condition.

I posted the scene in the code sharing thread. I made the first calculation with script 1 and it seems to work… you may or may not like this use of the PARAM to set two variables in a manner more useful (methinks) that just if X goes up, Y goes down, although that is part of it. Found an excellent use for MOD, also… and use for METRO as an aux script…

If we could have multiple PREs per row, then a simple DEL applied would ensure correct order. Even better, I think would be to have a ā€œDEL everything belowā€ command

with v2 when i add SCRIPT (calling one script from a command) being able to DEL SCRIPT x will be great.

1 Like

Hi, here is a little patch build around a " complex evolving sequencer " script on the Teletype. :kissing_smiling_eyes:

9 Likes

Is there a way to read values from the trilogy units? For example, the current pattern playing on white whale or the total number of patterns. WW.PATTERN returns 23 for some reason.