#45

snappy in the quick sense

#46

no prob! glad to finally have the time to work on firmware again, really want to push it closer to a release. should be able to post a new beta tomorrow which will include fixes for multiline editing as well.

ha, i didn’t even think of the other meaning :slight_smile:

and it made me look this up:

4 Likes
#47

hahaha so i guess there were a number of ways that could have been taken :joy:

2 Likes
#48

Found a bug in the current firmware, although it might be more for @Galapagoose

I was following along with the excellent Just Type studies by @dan_derks. Study #6 works fine when implementing it. However, if you save it, shut down your system, and reboot… Teletype will lock up after about 30 seconds or so. If I change scenes before the freeze, the TT won’t lock up. Interestingly, if I change scenes and then change back to JT #6, it won’t freeze. It only seems to occur if you boot with #6 and leave it running.

For reference, here is the file:
tt17s.txt (1.5 KB)

EDIT: If it helps, here’s everything on my i2c bus: ER-301, 1x TXi, 2x TXo, Just Friends

#49

this sounds very much like the bug @laborcamp discovered (and i was able to reproduce it easily as well). this is due to er-301 sending some stuff over i2c when it’s booted up, so what happens is if you have any i2c commands in your init script the conflicting i2c communications will cause TT to freeze. that’s why you don’t get it if you switch scenes.

brian (odevices) mentioned he was going to fix it in one of the 0.3 betas, not sure if this was done already or not, i need to update mine and retests. @laborcamp do you know if this was fixed?

#50

sorry this took a bit longer than anticipated, it’s quite weird how there seems to be not enough time for anything now that i’m not working. hopefully the next beta won’t take this long.

new 2.3 beta 3D2CCB9

teletype.zip (145.2 KB)
teletype.hex (491.1 KB)

what’s new:

  • multi line editing should not cause freezing now
  • commented out lines should properly move now
  • documentation on LSH and RSH fixed (thanks @rikrak!)
  • PN.HERE not updating tracker view fixed
  • “sticky” grid faders hopefully fixed
  • G.BTN.PR and G.FDR.PR will now work on disabled controls
  • fine faders not working properly with levels higher 127 - fixed

this beta also incorporates:

a note on multiline editing: i removed the ability to select an empty line (which is what caused issues) and added a bunch of boundary checks. i’m hoping this should take care of it but extensive testing is the key.

big thanks to everybody helping with testing, reporting issues and development!

12 Likes
Grid ops / integration
#51

Maybe I’m forgetting something, but I don’t remember writing this code. :face_with_raised_eyebrow:

#52

Excellent! Sounds robust. I will try my hardest to break it :nerd_face:

2 Likes
#53

This is fantastic! Can’t wait to try this new beta out. Not had so much free time for teletype explorations recently…

1 Like
#54

yeah, my mistake, i thought you already added that! are you still planning on working on it?

#55

re: L 0 32768 bug (L with these boundaries will cause TT to freeze).

the reason for this is int overflow causing the loop to never finish. i can fix this particular case, but looking at the code feels like additional discussion is needed.

it appears we intentionally allow I to be modified within the loop itself. so you could do something like this: L 1 10: I + I 2. this makes it really flexible but right now there is no protection around it whatsoever, so you could easily freeze TT with something like this: L 1 2: I 1.

how should this be fixed? the most obvious choice is limiting the total number of iterations. if we go with this option, should some fixed number be used? or should it calculate the number based on the specified loop boundaries?

#56

Came here to post this… Presumably the L 0 32768 bug will be caught as you enter the code and the upper limit changed to 32767. Or will it need to be evaluated at runtime?

Aside from the issue of “I”…

At the prompt,

Y 32768 results in Y = 32767

BUT

Y 32768; Y + Y 1 results in Y = -32768

AND

Z 999999; Z + Z 999999 results in Z = -2, for some reason

I would expect I to return the values 3,4,5,6,7,8,9,10,11,12 from this loop - what am I missing?

#57

32768 gets clamped to 32767, so you’ll get the same result using either (and if you enter 32768 in live mode and then press <arrow up> to see history it’ll be changed in history as well).

adding 1 to 32767 results in overflow and due to binary signed arithmetic you get -32768. so doing either one of these:

+ 1 32767
+ 1 32768
Y 32767; Y + Y 1; Y
Y 32768; Y + Y 1; Y

will give you -32768 (so in the L bug both 32767 and 32768 will cause the issue).

999999 will get clamped to 32767, adding 2 of those will result in overflow with the result being -2, as expected.

it increments I in each iteration, so what you’ll get will be 1, 4, 7, 10 (since the loop itself will increment I by 1 and then we are adding 2 on top of that). you can test it easily by doing L 1 10: P O I; I + I 2 and then checking pattern bank 0.

#58

Ah! I didn’t realise that “I” affected the Loop step!

I misunderstood the Manual entry for “I” from which I inferred that the step of the loop overwrites the value of “I”:

get / set the variable I, this variable is
overwritten by L, but can be used freely
outside an L loop

#59

basically, L A B: ... could be expanded to this:

  • set I to A (loop start), this is what’s meant by “this variable is overwritten by L”
  • does I exceed B (loop end)? if so, exit the loop
  • execute the loop command(s) (you are allowed to assign a different value to I here)
  • increment I by 1, go to step 2

for simplicity sake i’m only showing incrementing loop, but you could have a decrementing loop as well (by setting A to be higher than B).

#60

Many thanks for the explanation - it makes sense now.

I will ponder “I” for a while, in order to avoid derailing the thread any further… :smile:

#61

it occurred to me that the “resume screen on boot” feature would be nice to put back in, now that there’s also a grid screen (and because i just got an e-mail asking for start-in-tracker-screen to be reinstated)

i’ll try to get to it in the next week, but if someone else has time to spare you’ll help other new things get released on schedule :wink:

4 Likes
#62

Yes, this would be great, especially for those of use who want to use it sans keyboard in a live performance.

#63

should be an easy fix, i can add it to next beta. on related note, i’d like to also add ops for choosing what screen to show - this will be mainly so that you could control it from a grid without having to replug keyboard, but they could also be used in the init script so then you could have different screens shown by default for different scenes.

could be something simple like SCREEN x where x would be:

0 - live screen
1 - live screen with variables
2 - live screen with grid visualizer
3 - full screen grid visualizer
4 - tracker view

18 Likes
Monome ecosystem firmware development backlog
Teletype 3.+ feature requests and discussion
#64

i’m totally into this!

1 Like
Monome ecosystem firmware development backlog