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?
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.
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.
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.
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.
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.
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.
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.
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).
@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.
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.
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)
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…
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).