#1

Very exciting to see all the new developments for Teletype!
(Also means lot’s of catching up for me to do: new learning!)

Was just looking at the post regarding the Teletype grid integration and the grid display on TT:

Which reminded me, and maybe this is a good time to bring this up again:
One thing I was always hoping for, from the very first release of TT, is to be able to monitor the values in LIVE screen continuously. So, rather than punching in the thing I want to check the value for, and then have the value of the given parameter displayed for that exact moment only. For me, being able to se how the value evolves when the script is running is a huge help in the process of scripting. So, I find myself often punching in the parameter repeatedly in the LIVE screen, which is kind of silly.
Any thoughts guys?

5 Likes
(Teletype) 2.2 Release
A user's guide to the wonderful world of teletype ⌨
(Teletype) 2.2 Release Status
Grid ops / integration
(Teletype) 2.2 Release Status
(Teletype) 2.1 Release
#2

one workaround (and i understand it might not work for everybody or every situation) is copying the value you want to monitor to a pattern value and watching it on the tracker screen, i often use it in this manner. one benefit of doing it this way is that you can monitor multiple variables at once.

2 Likes
#3

Yes.
I have done it this way as well, but, as you point out, it certainly does not work for every situation. Not to mention it requires all sorts of steps/scripting, for something that feels like it “almost” is there, in the system, as a useful utility.

1 Like
#4

i like the idea of having a heads up view of variables. could be cool if there was an operator to use in the init script to turn on/off observation of a variable so you could avoid cluttering the live screen with variables you aren’t interested in keeping track of.

1 Like
#5

If anyone wants to design the display, I’d be happy to implement it. I gave it a shot, but it was really hard to determine which variables to show, how to make short labels, etc.

The layout is most of the work. If the community can hash out how it should look, it shouldn’t take me more than a day to put together functional code.

(Teletype) 2.2 Release Status
#6

Not sure about the vertical icon display when it is not needed for the grid display but how about a monitor view for variables on the empty live screen? Maybe it could be toggled on/off for each variable to keep it tidy. Something like
MONITOR X 1?

I think it was discussed some time ago and could be very useful for troubleshooting a script while working on it or just keeping track of your live input values.

#7

i should clarify that it’s not likely that i will include live variable monitoring as part of this change, what i had in mind was something considerably smaller. live monitoring (when or if it happens) deserves a bigger discussion - definitely good to keep it in mind though when talking about the icon arrangement.

edit: this was moved from another thread, so the context was lost. i was referring to the grid preview mode.

#8

Just to be clear.
What I am proposing is very much like what is there right now, where you type in the variable or property, and hit return, it just displays the current value of that item.
What I am asking for is that the displayed value be dynamic displaying the value as it changes when the script is running, instead of only showing the value when you hit return.
Ideal scenario would be to be able to enter several items (each added in separate line) with few values displayed dynamically.
Does that make sense?

And when you ask for a layout: do you mean an image that shows what that screen would look like with this functionality implemented? If so, I can definitely make that image.

2 Likes
#9

I’m not near my TT, but I’m wondering with WHILE could we write something like WHILE 1: X in the interactive console and get a running view of the variable. Might need a PRINT OP? Would also be useful to log things to the console from scripts.

#SCRIPT 1
X + X 1
IF GTE X 10: PRINT "RESETTING X"; X 0

Seems kind of useful for monitoring the status of a patch from the console? (my code might be wrong, and I might have called the interactive prompt the wrong thing, just rattling ideas off the top of my head without checking the docs for the right words).

#10

Oh, that’s an interesting solution, assignable watch slots! I really like that. It’s way better than trying to show them all.

Actually, what is needed is mostly a text file mock-up of where stuff goes on the screen, but if you can explain the factors of where text goes in an annotated image, that works too.

PRINT with custom text is a no-go, I’m afraid. The internals won’t support that.

2 Likes
#11

@sliderule here are a couple of images.
Fig.1 shows how this is implemented now
Fig.2 shows what the screen might look like. The idea is that you enter variables exactly the same way as we do now, except they display the values dynamically. And, as you enter subsequent variables to monitor, the previous one is bumped up by one line. Their one bumps the previous two up a line etc. The screen can fit comfortably six lines, so that would be maximum number of values monitored. Entering a seventh value, places it a the bottom of the stack, and the top one is kicked off the display and is no longer monitored.

23 PM
Screen Shot 2017-10-20 at 6.22.23 PM.png1650×1100 23.9 KB

Another variation would be to not only display the number, but also name of the variable as entered by the user. (So, for example: A = 14 etc.)

I am also including a photo mockup how that would fit with the icons:

TT_mockup
TT_mockup.jpg3878×2909 1.02 MB

Please let me know if I can help in any other way.
p.

#12

A couple of problems with this scheme:

  • Users can enter full expressions in the live mode
    • One solution is to only allow 1-operator get commands to be candidates for display
  • It doesn’t require an explicit command
  • It doesn’t allow re-assignment of any of the slots without pushing the top one off

I was thinking of something along the lines of:

  • Static areas on the empty 5-line space for about a dozen “watch” variables
  • Some sort of labels for each cell or a binary coordinate system with row and column headers.
  • A new mod: WATCH X: [post-command] that evaluates the post-command into slot X or binary coordinate X/Y.

What do you think?

3 Likes
#13

I was considering the simplest scenarios. So my suggestion is super minimal.

Do you think the one operator/variable solution is problematic? It makes sense to me. I suppose adding GET: or WATCH: command for entering the items to watch would work as well.

As to the slots reassignment. The scrolling up I am proposing seemed like an elegant extension to what is there now. I am not dead set on this, though. It just seemed simple/minimal.

If a set 6x2 grid is set up, where user can enter/assign particular items to watch, maybe instead of special mod, user can navigate that grid using the arrow keys on the keyboard, which can move the ‘cursor’ from slot to slot in the grid and/or back to the bottom command entry line/field if they need to enter full expressions to execute.

#14

my vote is for assignable slots, the reason being - with pushing values up as soon as you execute a new command your whole structure shifts, which would break the flow if you wanted watched variables to be in a specific order.

actually, not even assignable slots. just keep it very simple. we’re talking about just a handful of variables which would fit on one, maybe two screens. so a button or button combo to simply switch it off and on.

i assume for variables that get modified on get we simply display what their next value will be? (this will require evaluating them ahead of time)

#15

I suppose the 6 lines can just be assignable spots. So a cursor moving up and down (could be arrow keys or something else) to place specific items to watch into those spots might be the simplest solution. I am not sure if I would need to watch more than 6 items at the same time…

#16

Why not have, say, 3 slots, which can appear in the very top left corner, in the same row as the metro, etc indicators?

WATCH {1-3} : var

You can then see the values change from various screens.

#17

6 lines is a bit of a waste of screen space, though. Consider that the tracker can display 4 numbers wide with a row header and graphical lines drawn between them.

A 5 x 4 grid would be possible permitting X,Y addressing of the watch slots.

I don’t like the modal shift of selecting items on the watch grid, personally. It breaks the flow.

If you keep to WATCH X Y: [sub-command], you get the benefit of being able to configure things with the init script, and eventually with F (timeline-style functions).

I think it fits the ethos of teletype better. It’s simple and consistent and fairly powerful.

Display Layout Parameters

  • Pixel grid of 128 x 64
  • Font for numbers is mono-spaced 4 x 8 including 1,1,1,0 (:arrow_up::arrow_right::arrow_down::arrow_left:) padding
  • Font grid is effectively 32 x 8
  • Bottom 2 lines and top 1 lines are occupied
  • Effective final font area: 32 x 5
  • ANY pixel graphics are possible, but keeping to the style of the existing teletype interface is cleanest IMO
  • Mimicking the row numbers and style of the tracker would be my preference
  • Right justify numbers because you can bet the implementation will. :slight_smile:

By the way, your graphic is very clean. Thank you so much for your help! I really struggle with visual design.

I think that the screen could be better used, and this would clutter a now-clean status bar. There’s a whole lot of space unused on the live mode screen.

#18

how would WATCH work as a pre? what happens if you specify + A B - would it update whenever A or B change? what about WATCH: FLIP?

really cool idea but it’ll introduce complexity as you’d need to add a current state to any get op, and you would have to change every set op to set a dirty flag (unless there is a common place for every setter to do that).

#19

Yes.

If we can afford a second scene_state in RAM, we could check if it changed at every command call and set the dirty bit. Or at least check the variables or some subset of the state.

Geez, this and O pose a particular challenge. I’ll think about it while I’m falling asleep tonight and see how I can tackle this. Any other modify-on-access getters I’m forgetting?

1 Like
#20

checking just the variables should be computationally cheap, this might be the best option.

there is also DRUNK and TOSS :slight_smile:

and then you’d have difficulty with something like IN, PARAM and any remote getters…

1 Like