Tim_Buxton@UM.CC.UMICH.EDU (09/23/89)
For anyone who has to do a "demo" of anything on an IRIS, there is
now a really great tool for recording a whole demonstration once,
including all keystrokes and mouse movements at the speed you want,
then playing it back any number of times, at selectable faster
or slower speeds. It is called the "journal"
facility and just came out with 3.1g, I believe. "Journalrecord
filename.jou" begins the recording, and "journalend" stops it.
"Journalplay filename.jou" begins playback. Or, "journalchest" can
show a panel with record, stop, and playback buttons to do all
of the preceeding. If you aren't using this feature yet, I
recommend trying it. We plan to use it to distribute some
tutorials along with a new facetizer for BRL-CAD MGED files
called FRED.
Now to mention a few problems I have found:
1. There are problems going from one machine (4D/70) to the
other (4D/50). The commands seem to get given before the machine
is ready for them. There is a speed adjustment - will this help,
or is there a difference in the keyboard signals between machines?
I notice that keyboard entry is stored not by ASCII code, but
by keyboard code, twice per keystroke. If a speed adjustment
does not slow it down enough, would it make sense to multiply
all the numbers in the first field, which seems to be an
"event time" field, by some factor to slow it down more?
2. Stopping the journal playback can be done by pressing any
key or moving the mouse yourself. You are then totally out
of the playback, however; it will not start up again from that
point. For new users watching a tutorial, the ability to stop,
then resume would be invaluable. For giving presentations to
groups (SGI salespersons are you listening?) it would be
very helpful to be able to stop to answer questions or make
a point, then continue. The SGI Hotline person I asked about
this concluded after some thorough checking that "Pause" is
not supported, although they might try to support it at a
later time. Has anyone come up with a "Pause" feature on
their own?
I would like to hear about possible solutions to the above
problems, as well as kinds of demos/tutorials/presentations that
are being done by various users that could help all of us respond
the the perennial question "Could you show me what it can do?"
Thanks.
Tim Buxton
OptiMetrics, Inc.
Tim_Buxton@um.cc.umich.edu
gavin@krypton.sgi.com (Gavin A. Bell) (09/25/89)
Tim_Buxton@UM.CC.UMICH.EDU writes: >For anyone who has to do a "demo" of anything on an IRIS, there is >now a really great tool for recording a whole demonstration once, >including all keystrokes and mouse movements at the speed you want, >then playing it back any number of times, at selectable faster >or slower speeds. It is called the "journal" >facility and just came out with 3.1g, I believe. ... goes on to mention two problems with journalling: playback on different machines, and not being able to pause the playback. The real problem with journalling is synchronization; playing back a journal recording of 'dog' twice in a row, you will end up in two different places, since small changes in when the program gets mouse events have large effects later. If this isn't critical (in demos where you won't crash if the 'bank left 20 degrees' is interpreted as 'bank left 18 degrees'), it can work fairly well. Having different scripts for different machines is one solution to the speed problem; recording on the slowest machine often works, too. However, a lot of different things can affect machine speed-- how loaded it is, if disk files have to be accessed over NFS, etc. The pause problem is much easier. You have the journalling code on your system; look in the files /usr/NeWS/lib/NeWS/journal.ps and /usr/NeWS/lib/NeWS/journalUI.ps. I've often considered adding a few options to the journalling stuff, including a pause feature (I've just never had the time to do it). There is one bug you should know about: If a GL program does a setvaluator() call, it will cause the journal file to stop. The journal playback gets confused, and thinks that the user has done something to stop the journalling. --gavin
ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) (09/26/89)
In article <4931133@um.cc.umich.edu>, Tim_Buxton@UM.CC.UMICH.EDU writes: > For anyone who has to do a "demo" of anything on an IRIS, there is > now a really great tool for recording a whole demonstration once, > including all keystrokes and mouse movements at the speed you want, > then playing it back any number of times, at selectable faster > or slower speeds. It is called the "journal" > facility and just came out with 3.1g, I believe. "Journalrecord > filename.jou" begins the recording, and "journalend" stops it. > "Journalplay filename.jou" begins playback. Or, "journalchest" can > show a panel with record, stop, and playback buttons to do all > of the preceeding. If you aren't using this feature yet, I > recommend trying it. We plan to use it to distribute some > tutorials along with a new facetizer for BRL-CAD MGED files > called FRED. > > Now to mention a few problems I have found: > > 1. There are problems going from one machine (4D/70) to the > other (4D/50). The commands seem to get given before the machine > is ready for them. There is a speed adjustment - will this help, > or is there a difference in the keyboard signals between machines? > I notice that keyboard entry is stored not by ASCII code, but > by keyboard code, twice per keystroke. If a speed adjustment > does not slow it down enough, would it make sense to multiply > all the numbers in the first field, which seems to be an > "event time" field, by some factor to slow it down more? The journalling mechanism is based on the NeWS journalling capabilities with some convenient scripts -- journalrecord, journalend, and journalplay -- used as wrappers for driving a remote machine or terminal, or from within a shell script. The journalchest is also a wrapper for simple driving of the recording, stopping, and playback mechanisms. Mouse and keyboard events are recorded in a journal file simplay as an event and a timestamp for when the event occured. Upon playback, events are played back with the same timing as they were recorded. Since there is variance in the amount of time it takes for the system to react to events such as starting applications, it is very possible for the playback mechanism to get ahead of the system. We humans can adjust for these variations but the playback mechanism only has a gross playback speed adjustment. Using the playback speed adjustment (journalplay -p <speed-multiplier>) should help to some degree. The keyboard does not come into play as all of the mouse and keyboard events are simulated in 4Sight and never actually use the keyboard or mouse. In my experience with the journalling, I recommend you do make all of your mouse actions while recording slow and deliberate. It is very easy to go zipping through a menu while recording and end up with the wrong menu selection during playback. Also, when starting applications with the mouse wait 5-10 seconds after you see the window outline before manipulating the window outline to place the window. This will allow for variance in the amount of time required to launch an application on a 4D/70 versus a slower 4D/50. Because of system speed variations, don't try to use journalling for recording real-time interactive applications like "flight". However, it is quite satisfactory to use journalling for recording non-real-time demos. I used it to record a fairly sophisticated "live" demo we did for the Personal Iris unveiling a year ago. > > 2. Stopping the journal playback can be done by pressing any > key or moving the mouse yourself. You are then totally out > of the playback, however; it will not start up again from that > point. For new users watching a tutorial, the ability to stop, > then resume would be invaluable. For giving presentations to > groups (SGI salespersons are you listening?) it would be > very helpful to be able to stop to answer questions or make > a point, then continue. The SGI Hotline person I asked about > this concluded after some thorough checking that "Pause" is > not supported, although they might try to support it at a > later time. Has anyone come up with a "Pause" feature on > their own? > I cannot comment on implementing Pause, you could try modifying: /usr/NeWS/lib/NeWS/journal.ps if you are up to a challenge. > > I would like to hear about possible solutions to the above > problems, as well as kinds of demos/tutorials/presentations that > are being done by various users that could help all of us respond > the the perennial question "Could you show me what it can do?" > Thanks. > > > Tim Buxton > OptiMetrics, Inc. > Tim_Buxton@um.cc.umich.edu > --- Dave -- ------------------------------------------------------------------------------- Cosmo Ciemo, Silicon Valley Dude I was traipsing through the fields of my mind when I stepped in something that smelled rather ripe. -------------------------------------------------------------------------------
msc@ramoth.esd.sgi.com (Mark Callow) (09/26/89)
In article <4931133@um.cc.umich.edu>, Tim_Buxton@UM.CC.UMICH.EDU writes: > > For anyone who has to do a "demo" of anything on an IRIS, there is > now a really great tool for recording a whole demonstration once, > including all keystrokes and mouse movements at the speed you want, I'm glad you like it. I put in a lot of unscheduled time to make the journalling package usable with GL clients as well as NeWS clients. Please note the caveats on the man page (journalchest(1w)). Due to the nature of the package these are largely unavoidable. The package is very useful as it stands which is why I released it. > > Now to mention a few problems I have found: > > 1. There are problems going from one machine (4D/70) to the > other (4D/50). The commands seem to get given before the machine > is ready for them. There is a speed adjustment - will this help, > or is there a difference in the keyboard signals between machines? > I notice that keyboard entry is stored not by ASCII code, but > by keyboard code, twice per keystroke. If a speed adjustment > does not slow it down enough, would it make sense to multiply > all the numbers in the first field, which seems to be an > "event time" field, by some factor to slow it down more? There is no difference in keyboard signals. Journalling records the keyboard scan codes. Translation happens during playback. What kind of keyboard problems are you seeing? The speed adjustment will help with things like windows not being up before button clicks are delivered. The first field is a timestamp so that the events can be played back at exactly the same relative times as they were recorded. When you adjust the speed control guess what it does - yes it multiples the time stamps by a factor. > > 2. Stopping the journal playback can be done by pressing any > key or moving the mouse yourself. You are then totally out > of the playback, however; it will not start up again from that > point. For new users watching a tutorial, the ability to stop, > then resume would be invaluable. For giving presentations to > groups (SGI salespersons are you listening?) it would be > very helpful to be able to stop to answer questions or make I would love to add a pause feature. Unfortunately I haven't been able to think of a way of doing so that wouldn't rob useful keys or key combinations from clients. If anyone has any ideas, please let me know. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."