#379

Well, shiver me timbers, that’s a bloody elegant solution! Thanks @GoneCaving !!!

1 Like
#380

Is anyone using TT to control Kria?
That was my plan. I just updated firmware and got started with what I thought was pretty basic stuff, alas…

A KR.PAT
B RRAND SUB A 1 ADD A 2
IF EQ A 15 : KR.PAT 0
ELSE : KR.PAT B

This script is crashing (freezing) TT and Kria/Grid
It runs, as expected, for a while. Maybe a few minutes. Then freezes. The idea is for it to run indefinitely…
Please, somebody, point out the logical mistake I’ve missed… I haven’t worked with TT for maybe 18 months or so, so I’m certainly rusty!
The project I’m working towards has a deadline and it’s really soon…

2 Likes
#381

This also just crashed/froze.
It ran for 4 or 5 minutes and then TT froze. Kria/Grid didn’t freeze.
Not sure if I should be posting here or in the 1.3 thread?

A KR.PAT
B RRAND SUB A 1 ADD A 2
KR.PAT WRAP B 0 15

1 Like
#382

I am sorry to hear about your deadline, that’s tedious when something is not working.

Apart from the experience that the new firmware updates are not working flawless in general in this case A might geht over 15 with a RRAND step by 2 at 14 and the freeze could occur when it reaches a value Kria can not handle anymore.

I just learned using MOD as an elegant way to keep values in a working range (it’s a few posts above yours in this thread). You could try this and monitor A too from time to time with the other script to check if this was the issue so it can be fixed.

#383

Yes, I think this should work - so posting it on the 1.3 thread would be a good way to collect everything.

#384

I suspect this is caused by the i2c read issues mentioned in the following thread

The fact that Kria continues to work would also suggest the issue is on the TT end.

#385

Yes, this could probably be - it’s a shame that teletype remote is not working reliably.
:cry:

#386

hit a roadblock with the teletype loop commands that don’t make sense to me. i have a pretty simple command, like this

L 1 4 : TR.PULSE A

my expectation is that upon execution, output A will pulse 4 times (as determined by it’s TR.TIME value), but it only pulses once. is this behavior by design? can anyone think of a simple way to have output A trigger 4 times in a row in a single script execution (multiple lines are fine)?

fwiw, i expected the loop command to be syntactically similar to python code like this

for x in range(3)

#387

Yes, that’s expected behaviour. Loop counts a variable I and executes a command several times on an instant with the changed I as an parameter. TR.PULSE I would trigger four outputs simultaniously.

#388

so loops are only useful when you use the I variable?

The ‘we do this all the time’ section here http://monome.org/docs/modular/teletype/studies-7/ suggests that the pulse should be executed 4 times.

#389

Yes, I would say so. And they loop, in this case four times, instantly, without delay between the single loops.

Yes, that’s right - you don’t have to use I. But the four pulses would be executed on the same trigger input not on four serial trigger inputs.

It’s like having four lines of TR.PULSE A in one script. You won’t hear four pulses then.

#390

TIME controls the length of the pulse, not a delay between pulses.

I think you might want to use the M script?

Teletype Studies 2: Curves and Repetition

#391

not sure the M page would get me any closer to a solution, i want to get 4 sequential trigger pulses from one trigger input.

if i’m understanding correctly now, the loop command executes the command specified within it N times at once instead of N times sequentially?

once again using python as a comparison, if i have a function that takes 2 seconds to complete and i execute it in a for loop, the function is not executed 4 times at the same moment, it is executed sequentially.

1 Like
#392

You could use a stack or a pattern to get four pulses evenly spaced apart from a trigger input.

Loops execute as fast as possible. They are sequential, but happening so fast it’s not going to appear to be sequential in the usage you’re proposing.

#393

regardless of speed of execution, if it was sequentual then the pulses shouldn’t happen all at once, no?

e.g. if my pulse time is 100 and the loop is sequentual, then pulse 1 will occur for 100, pulse 2 for 100, pulse 3 for 100, pulse 4 for 100. the total time of execution would be close to 400.

#394

The start of each pulse is happening sequentially, but no pulse start is waiting for any pulse end.

#395

aha, that is where this is breaking down for me. so the four pulses essentially overlap one another, whereas my expectation was that one would finish then another would begin. thanks!

1 Like
#396

playing with the stack command, it puts me in a similar situation as the loop. this may be overly difficult without having the ability to write a ‘del’ command into a loop or stack.

#397

You can use the M script to pop items off the stack. So when you want to “schedule” 4 triggers, you push them on the stack then set the metronome period and enable the M script, which will disable itself when the stack is empty.

#398

yeah, that does seem to be one way to do this. thanks!