#335

I would love teletype to always count from 0, like in patterns. So ins + out would be 0-3, scripts and trigger ins 0-7. Would make code more elegant, and cleaner.

2 Likes
#336

As much as I relate from a coding perspective, it would render quite a disconnect with the labelling on the panel. Put another way, I think i’d find having a 0-indexed panel quite strange…

1 Like
#337

I’d love a zero-indexed panel… right now, I’m rocking the DEVICE.FLIP teletype to keep cables away from the screen and have an upside down 4 indexed panel :wink:

#338

I dont get it. This is a computer, the user know it, why hide it?

But you’re right: it’s exactly the stuff that’s printed on the front panel that’s counted from 1, which from a coding point of view is totally arbitrary.

#339

Is there a timeout/max iteration for the W (while) loops? I encountered some strange behavior in the latest beta. I’m not sure if it was there previously.

#340

Teletype will terminate while loops at 10,000 iterations, you could recompile the firmware with a different (16-bit) value, but I think like many decisions in the firmware this is probably a constraint imposed to prevent locking up the module. Really everything happening in all scripts is fighting for time in the same event loop, so this kind of limitation is generally necessary to keep things acting like scripts are independent and so on. I do really like the idea of letting inputs be triggered on rising/falling/either edge though, seems like a tidier solution to this kind of problem.

#341

So approximately how long would that be in actual time. I mean I’m looking at gates on the order of 4 beats @ 110 bpm…

And so if the max is 10000 iterations, shouldn’t I be able to list multiple W statements per script like:

W STATE 1: TR 1 1
W STATE 1: TR 1 1
TR 1 0

In order to achieve 20000 iterations? I tried that, it doesn’t seem to work

#342

It’s basically instant, quick enough to not impact timing of other scripts and delayed events and stuff. Would probably need to set up a scope to get the exact timing. It’s also a limit for the whole script/execution context – if the iteration limit is exceeded it will just break out of any while loop it encounters after at most one iteration, continuing to the next line. Consider:

I 0; J 0; X 0; Y 0; Z 0
W < I 15000: I + I 1
W < J 15000: J + J 1
X I; Y J; Z + I J

Which when executed results in X = 10000, Y = 1. You can set these loop bounds to other values but Z will be at most 10001.

2 Likes
#343

OK then…I mean I can setup an M script and poll IN, but it’s quite a bit less elegant. I know we have been talking about implementing the negative edge triggering for a while, but I guess there really isn’t much interest aside from myself.

2 Likes
#344

This is me registering interest in falling edge triggering of scripts.

I had no idea about the W loop limitation, and now I need to go back and edit some of my old suggestions… :neutral_face:

4 Likes
#345

teletype.hex (573.5 KB)

SCRIPT.POL s p   # set script s (1-8) to fire on polarity p
                 # 1 - rising edge, 2 - falling edge, 3 - both
SCRIPT.POL s     # get polarity of script s (1 - 8)
                 # 0 when script index is out of bounds
$.POL s p        # aliases for above
$.POL s

Polarity of each script input is indicated in LIVE mode with the mutes icon - if the falling edge is active, the next pixel over for the corresponding trigger will be dimly lit as well, so if rising and falling edge triggers are on for all inputs this will look like two continuous rows of pixels. Hopefully that’s not too hard to see, seemed like some visual indication was necessary and this seemed to sort of make sense conceptually.

13 Likes
#346

Crazy thought - what if we mashed together falling scripts with the old concept of “shadow” scripts?! So each script would have a corresponding script that could trigger on each falling edge, default would be blank of course. This also allows for a logical way to expand the number of scripts.

Would still need a reasonable way to go in/out of the falling edge script mode, and might need a new op to programmatically trigger a falling edge script.

Suffice it to say, I’m super into falling edge triggered scripts in general, regardless of how they’re implemented (my use case is triggering based on gates from a keyboard)

EDIT: the Polarity ops above actually is super clean, that probably makes the most sense :metal:

#347

Wow. This is cool. Unfortunately I’m on business travel until Thursday w/o my teletype but cannot wait to try this out

#348

Hi,

I loaded the firmware. It says V2.2.0-ALPHA.7-243-GB9D. Is that correct? Negative edge detection is working and it is following the gate as expected! Thanks.

Thanks.

Geremy

1 Like
#349

That is not the correct version number, but yes that is the correct firmware if you’ve got $.POL. Due to a set of wacky line-ending related circumstances the part of the build that updates the version number is currently broken on my machine. Sorry for the confusion.

How would folks feel about $.POL i 0 meaning “trigger on neither edge”? This would be consistent with interpreting the polarity of a script as a 2-bit number, with one bit for each edge. This seems like it might be more convenient in some scripting scenarios but not sure if it would be confusing to have an extra way to mute.

# M
X PARAM
L 0 7: P I & X LSH 3 * 2 I
L 0 7: P I RSH P I * 2 I
L 0 7: $.POL + 1 I P I

Also how would the UI for this work, would the mute pixels for that input just both be off – and does using the mutes icon for indicating polarity feel okay in the first place?

2 Likes
#350

Is there a $.POL i getter? could make for interesting script logic.

#351

Yup! Currently you’ll only get 0 out of $.POL i if i is not 1-8. If $.POL 1 0 meant “fire on neither edge” then this return value might still make sense (certainly if you say $.POL 15, nonexistent script 15 fires on neither edge) but it could also return -1 for “bad argument” I guess. 0 feels maybe more idiomatic.

#352

I still can’t believe the shadow script proposal got ditched…

Such a perfect match for the grid ops. And “functions” without sacrificing trigger inputs in general…

1 Like
#353

no one working on it != ditched

3 Likes
#354

Yes, but IIRC the proposal got mainly disapproved back then.