User input/interface in a jit.window

    Mar 15 2017 | 10:06 pm
    Ack. Going crazy with this one. I need to overlay a user interface on top of Jitter graphics. The background is generated video and graphics; on top, I need to take user text input. Basically, think "web form on top of live video."
    I've tried rolling my own using a combination of javascript, key and jit.lcd, but things are quickly getting too complex. Any suggestions for a direction here?
    Thanks, Eric

    • Mar 16 2017 | 1:12 am
      hi Eric
      you could use the jit.window ability to route the mouse coord
      here is an example with
      and here is and example with and jit.window
      you could either use or jit.phys to id your geo (flag picked)
      there you go usable pickable UI
      Let me know if you need more details and examples
    • Mar 16 2017 | 1:43 am
      Thanks, phiol, but I'm looking for text input. I need to be able to put multiple text entry boxes in a window and have the user be able to type into them. Even one text input box would be nice.
    • Mar 16 2017 | 2:12 am
      maybe this will help .
      basically use poly~ and then fill a named coll, then send to appropriate poly~ each containing it's position and correct size etc...
      see how users would write text in the helpfile
      maybe I'm misunderstanding you
    • Mar 16 2017 | 12:42 pm
      Maybe I'm missing something in your examples, but I need the user to have fields to type into - e.g. First Name, Last Name, Email Address - on top of Jitter video.
    • Mar 16 2017 | 1:16 pm
      Some further thoughts: A hack-y solution could be to build a web form, display it on a second (preferably virtual) monitor, force it to remain the active window and capture it with jit.desktop. Hardly need to point out how convoluted this would be.
      If objects like jweb, jsui or bpatcher could output to jitter matrices instead of only patcher windows, this would be a plan of attack. I don't suppose there's a way to do something like this (again, without the aid of jit.desktop).
      (As an aside, I've been working in Max 6 and don't know if Max 7 has new tools that would help. Preferring to keep this in 6, but no problem switching to 7 if it will enable a solution.)
      Thanks, Eric
    • Mar 16 2017 | 4:11 pm
      This may or may not suit your needs, but how about a textedit object on top of a jit.pwindow? In this example, the background color of the textedit is set to 0% opacity, the border color is set to 50% opacity, and the text color is set to 100% opacity.
    • Mar 16 2017 | 4:24 pm
      Thanks, Chris. This gets me a lot closer - probably workable.
      I'd love for a more elegant solution to this. A general one would be the ability to render certain Max objects (along with user interaction) into matrix format. Probably a tall order, but doing this would be a big step up, integrating Max's UI capabilities into Jitter graphics/video. Cycling?
    • Mar 16 2017 | 10:47 pm
      Hi eric
      I slapped this together in 2 secs to illustrate what I mean simply click in the red square , type , press enter to clear
    • Mar 16 2017 | 11:00 pm
      also a bpatcher (containing the textedit objects) over the top of jit.pwindow may help to streamline /modularize/simplify the patching of of it...
    • Mar 17 2017 | 12:14 am
      Regarding the last two ideas:
      I already have a partial implementation with javascript, jit.lcd and key that does a similar thing to your patch, Phiol. I'm trying to avoid that though, as I have issues of multiple fields, focus and the need to rewrite code every time to change the UI.
      Regarding the objects-on-jit.pwindow solution, I realized that this isn't going to work either, as I am using a jit.window, in full screen mode - unless there is a way to later Max objects on a jit.window or full-screen an actual Max patch.
    • Mar 17 2017 | 12:16 am
      I may attempt a jit.desktop solution next. However, I'd rather not carry around an extra screen just to use as a drawing area. Is there a way around this - a virtual screen, or off-screen drawing? (I'm going to try the latter now)
    • Mar 17 2017 | 12:28 am
      Well, tremendous hack, but it looks like I can position a window just off the screen to the right, and set jit.desktop coordinates past the screen dims. (Negative numbers do this interesting stretchy effect.)
      If this looks like it's going to work, the next thing I'd need to do is control focus among textedit boxes programmatically (without user clicks).
    • Mar 17 2017 | 12:32 am
      Aha, "select" does that! (Sorry to be "live tweeting" my progress.)
      Still, not exactly elegant...