Screen Editors Research Articles

Intuition in creative film editing practice: using phenomenology to explain editing as an embodied experience

ABSTRACT Intuition has long been associated with creativity in editing but not easily explained when it comes to unravelling the editor's creative process. An editor's physiological and cognitive response to the film material they work with plays a significant role in developing a rhythmic storytelling technique and style that is ‘right’ for the film. Creative film editing practice is a major focus of my research and the inspiration in developing the education resource, The Art of Editing: Australian Screen Editors Discuss Creativity in Editing (2015). As much as I draw on interviews from this resource, I will further investigate the source of the editor's intuitive process in reference to phenomenological film theory, specifically the work of Vivian Sobchack and Jennifer Barker, who explore the embodiment of film. Both Sobchack and Barker argue the ‘body of the spectator’ and the ‘body of the film’ as reciprocal to the ‘existential act of viewing’. As such, a phenomenological film theory that moves beyond the confines of critical film studies to one that embraces the ‘act of viewing’ resonates with the editor's intuitive process as the ‘first audience of the film’ which has a direct impact in shaping the audience's embodied experience of a film.

Insights into teaching creativity in editing

ABSTRACTIn my experience, teaching film editing has always presented a challenge in terms of aligning the creative with technical expertise. The technology, as a tangible commodity, is essentially taught in an experiential learning environment by engaging students in hands-on practical exercises to learn the software and basic editing technique. The challenge of teaching the creative editing practice is less tangible in that it requires a great deal of contextualising in terms of content and problem solving, as aligned with ‘creative outcomes’.This paper will explore the challenge of teaching creativity in editing and in doing so I will discuss editing as a ‘hidden art’, and the more abstract phenomena of intuition, rhythm and pacing as aligned with creative outcomes. Furthermore, I will discuss ‘best practice’ in teaching editing in reference to the nexus of theory and practice, the collaborative nature of teaching creativity in a studio-based environment, and the development of the teaching resource The Art of Editing: Australian Screen Editors Discuss Creativity in Editing, that offers new insights into teaching creativity in editing.

Design & Development of a New and Efficient Approach for Line Text Editing in Turbo Pascal 5.5 for Windows/Netware/MS-DOS*

Text editors come in the forms viz. Line editors, Stream editors, Screen editors, Word processors, Structure editors, etc. There are many text editors provided with Windows viz. Notepad, WordPad, Microsoft Office Word, etc. The MS-DOS editors viz. EDLIN and EDIT also work in Windows. MS-DOS had very good word processors viz. Word Star, Word Perfect, etc. All the editors which work in MS-DOS, also work in the Novell’s Netware OS as well. But none of the above editors is interactive. The process of entering the programs/text shall be greatly enhanced, for the newcomers, if the editor is an interactive one. This paper gives the design & development of a new and efficient approach for line text editing, the most basic and fundamental editing, in Turbo Pascal 5.5 for Windows/Netware/MS-DOS OS. It is proposed to give a new, interactive, and more user friendly approach to line text editing for document / non document (program) files using singly- linked lists. A menu driven program is designed and developed which works like an IDE, Integrated Development Environment, available in most of the programming languages viz. Turbo C, Turbo Pascal, etc . The program displays all the options and once a user chooses a particular option, he is prompted further interactively. The program is fully tested on Windows XP, with total RAM = 256 MB and shall work efficiently on Novell’s Netware and MS-DOS as well. This research work has, in all, twenty eight options and is academically (not available in any book) very useful for the Computer Science & Engineering and Information Technology disciplines.

MetaPath: An electronic knowledge base for collating, exchanging and analyzing case studies of xenobiotic metabolism

The MetaPath knowledge base was developed for the purpose of archiving, sharing and analyzing experimental data on metabolism, metabolic pathways and crucial supporting metadata. The MetaPath system grew out of the need to compile and organize the results of metabolism studies into a systematic database to facilitate data comparisons and evaluations. Specialized MetaPath data evaluation tools facilitate the review of pesticide metabolism data submitted for regulatory risk assessments as well as exchange of results of complex analyses used in regulation and research. Customized screen editors called Composers were developed to automate data entry into MetaPath while also streamlining the production of agency specific study summaries such as the Data Evaluation Records (DER) used by the US EPA Office of Pesticide Programs. Efforts are underway through an Organization for Economic Co-operation and Development (OECD) work group to extend the use of DER Composers as harmonized templates for rat metabolism, livestock residue, plant residue and environmental degradation studies.

Empirical software research

Punched cards were already obsolete when I began my studies at the Technical University of Munich in 1971. Instead, we had the luxury of an interactive, line-oriented editor for typing our programs. Doug Engelbart had already invented the mouse, but the device was not yet available. With line editors, users had to identify lines by numbers and type in awkward substitution commands just to add missing semicolons. Though cumbersome by today's standards, it was obvious that line-oriented editors were far better than punched cards. Not long after, screen oriented editors such as Vi and Emacs appeared. Again, these editors were obvious improvements and everybody quickly made the switch. No detailed usability studies were needed. "Try it and you'll like it" was enough. (Brian Reid at CMU likened screen editors to handing out free cocaine in the schoolyard.) Switching from Assembler to Fortran, Algol, or Pascal also was a no-brainer. But in the late '70s, the acceptance of new technologies for building software seemed to slow down, even though more people were building software tools. Debates raged over whether Pascal was superior to C, without a clear winner. Object-oriented programming, invented back in the '60s with Simula, took decades to be widely adopted. Functional programming is languishing to this day. The debate about whether agile methods are better than plan-driven methods has not led to a consensus. Literally hundreds of software development technologies and programming languages have been invented, written about, and demoed over the years, only to be forgotten. What went wrong?

Neural networks and fuzzy-logic control on personal computers and workstations

From the Publisher: Neural Networks and Fuzzy-Logic Control introduces a simple integrated environment for programming displays and report generation. It includes the only currently available software that permits combined simulation of multiple neural networks, fuzzy-logic controllers, and dynamic systems such as robots or physiological models. The enclosed educational version of DESIRE/NEUNET differs for the full system mainly in the size of its data area and includes a compiler, two screen editors, color graphics, and many ready-to-run examples. The software lets users or instructors add their own help screens and interactive menus. The version of DESIRE/NEUNET included here is for PCs, viz. 286/287, 386/387, 486DX, Pentium, P6, SX with math coprocessor.

Cadenza: A Music Description Language

The development of computing has been motivated by a desire to automate or, at the very least, ease manual tasks. Nowhere does this have greater impact on people than in the committing of ideas to paper. Text processing has undergone a revolution from the first simple line editors (used almost entirely for program development rather than publishing), to complete systems that will take text and graphics, edit them on a single screen, and then present the finished whole for publication on a phototypesetting printing press. Representing text on the screen in a basic form is very simple. There are only 26 letters (for English) and a further handful of extra punctuation symbols that must be used to convey information. Together with their upper case representation, the entire set can be reduced to fewer than 128 characters, which gives us the familiar ASCII code set. This restricted character set, with a few additions, has made it possible to produce editors of all sorts, from simple line editors to sophisticated screen editors and desktop publishing systems. Music, however, is far more complex in its representation. Although it has a comparable number of symbols to represent it, they are put together in a considerably more elaborate way. There are very few music editors at present, and almost all of them are based on a graphical screen editor approach. Thus, they require relatively expensive computers that, together with a laser printer, can cost tens of thousands of dollars. There are some available that are based on small personal computers, but they do not generally offer the range of typesetting features of large programs. Some form of text entry of music would allow written music to be prepared on relatively simple machines that only provide a simple line or screen text editor and would provide a standard file format for the interchange of data between various graphical music editors. The Cadenza language is based solely on text and therefore would be easy to generate on any word-proCadenza: A Music Description Language

Technical support program for APL related question

A technical support program was created to assist Data Processing Support Personnel at the Travelers Insurance Co. in answering employees' commonly asked questions about APL. The Travelers Data Processing (DP) Department, in previous years, maintained a single centralized “help” number in Computer Science that employees could use to ask questions related to computers or computing. In order to foster a closer working relationship between employees in the different business areas and their local DP Support staff, the central number was eliminated and people were directed to their local DP Support. Questions about the more commonly used languages in Data Processing, such as COBOL, are more easily redirected to the local DP Support staff than are questions about the more uncommon languages such as APL. Many of the APL questions asked of the help line were in reference to the particulars of using APL in the Travelers environment. The solutions to these types of questions are not easily found in the reference manuals, are not centrally documented, and are frequently passed by word of mouth. Some of the more common APL questions that came to the help line include: How do you get APL characters with 3270 emulation? What's the best way to get a print of a workspace? How do I use the full screen editors? How do I run APL in batch? How do I move a variable from host APL to LOTUS? Is there any way to make my function run faster? APL is such a versatile language that there are usually several ways to perform these and most other tasks. The quality of the solution given for the question at hand can range from slow and cumbersome to quick and easy. Most of the DP Support staff have limited exposure to APL, so when they search for a solution to a problem they might take a painful route and end up cursing APL when it doesn't work efficiently. To help the DP Support areas quickly and effectively answer these types of questions, and to have a common source of the most up to date information on The Traveler's APL environment and utilities, a diagnostic tool was written using the Socrates * Knowledge-Base Management System software. The software is an indexed decision tree that guides users by menu picks to an easy-to-read solution to their problem. It is compatible with commonly used terminal emulation programs, so that the user can toggle back and forth from a host session to try out suggested solutions. It is also compatible with the commonly used software generated APL characters (e.g. STSC's ECDCHAR.COM), so that APL characters can be used in the solution files. An index file is created for the entire set of text in the support software so that the user can quickly jump to one of the references of a requested text string. The index was built without reference to common words (like some, the, and, of etc.) to make the it as efficient as possible. Calls to the help line were tracked for several months to insure that the answers to commonly asked questions were covered. The application was structured so that the more basic the question, the more basic the solution. For example, the solution file to what a VALUE ERROR means assumed a lower level of APL skill than the description of what a return code of 445 from Auxiliary Processor 210 means.

Row replacement algorithms for screen editors

Interactive screen editors repeatedly determine terminal command sequences to update a screen row. Computing an optimal command sequence differs from the traditional sequence comparison problem in that there is a cost for moving the cursor over unedited characters and the cost of an n -character command is not always the cost of n one-character commands. For example, on an ANSI-standard terminal, it takes nine bytes to insert one character, ten to insert two, eleven to insert three, and so on. This paper presents an O ( MN ) dynamic programming algorithm for row replacement where an n -character command costs α n + β for constants α and β. M is the length of the original row and N is the length of its replacement. Also given is an O ( Cost × ( M + N )) “greedy” algorithm for optimal row replacement. Here Cost is the optimal cost (in bytes) of the replacement, so the algorithm is fast when the require d update is small. Though the algorithm is rather complicated, it is fast enough to be useful in practice.

A new environment for interactive neural network experiments

DESIRE/NEUNET is a new environment for interactive experiments with neural networks. Simulations on 80386/80387-based personal computers execute faster than in Microsoft FORTRAN. Screen-edited programs, moreover, execute directly without the usual annoying wait for program translation. A true (not incremental) compiler, small and extra fast, is built into a powerful interpreter and compiles all time-critical operations directly into memory. A reasonable matrix language makes it easy to split large neuron interconnection matrices into smaller, intuitively meaningful pieces. DESIRE/NEUNET includes two built-in screen editors, a DOS shell, a debugger, and a journal-file generator, plots graphs, and lets users write their own help screens and menus. The new program admits up to 16,383 neuron interconnections under MS-DOS and will be ported to AT clones.

A Keystroke Analysis of Learning and Transfer in Text Editing

Two experiments studied the acquisition and transfer of text-editing skill. The first experiment, originally reported in Singley & Anderson (1985) but reanalyzed in greater detail here, found nearly total transfer between two similar line editors and partial transfer from the line editors to a screen editor. Analyses of the keystroke data revealed that the majority of the improvement during both learning and transfer was concentrated in the planning components of the skill. The second experiment found little evidence for negative transfer between a pair of screen editors designed for maximal interference using a classic interference paradigm. The few instances of negative transfer observed were better characterized as the positive transfer of non-optimal methods rather than instances of true procedural interference. These results support an identical elements model of transfer based on a production system representation of cognitive skill. The relative magnitudes of transfer observed were consistent with detailed measures of production system overlap. In addition, localized transfer sites were hypothesized and identified through a series of microanalyses. Finally, specific transfer predictions based on the differential practice of general and specific components were tested and confirmed.

A Keystroke Analysis of Learning and Transfer in Text Editing

Two experiments studied the acquisition and transfer of text-editing skill. The first experiment, originally reported in Singley and Anderson (1985) but reanalyzed in greater detail here, found nearly total transfer between two similar line editors and partial transfer from the line editors to a screen editor. Analyses of the keystroke data revealed that the majority of the improvement during both learning and transfer was concentrated in the planning components of the skill. The second experiment found little evidence for negative transfer between a pair of screen editors designed for maximal interference using a classic interference paradigm. The few instances of negative transfer observed were better characterized as the positive transfer of nonoptimal methods rather than instances of true procedural interference. These results support an identical elements model of transfer based on a production system representation of cognitive skill. The relative magnitudes of transfer observed were consistent with detailed measures of production system overlap. In addition, localized transfer sites were hypothesized and identified through a series of microanalyses. Finally, specific transfer predictions based on the differential practice of general and specific components were tested and confirmed.

Transfer between text editors

This paper describes a successful test of a quantitative model that accounts for large positive transfer effects between similar screen editors, between different line editors and from line editors to a screen editor, and between text and graphic editors. The model is tested in an experiment using two very similar full-screen text-editors differing only in the structure of their editing commands, verb-noun vs noun-verb. Quantitative predictions for training time were derived from a production system model based on the Polson and Kieras (1985) model of text editing.

Transfer between text editors

This paper describes a successful test of a quantitative model that accounts for large positive transfer effects between similar screen editors, between different line editors and from line editors to a screen editor, and between text and graphic editors. The model is tested in an experiment using two very similar full-screen text-editors differing only in the structure of their editing commands, verb-noun vs noun-verb. Quantitative predictions for training time were derived from a production system model based on the Polson and Kieras (1985) model of text editing.

Software Reviews : ThinkTank 2.0 (An Outline Processor) Reviewed by Werner F. Grunbaum, University of Missouri—St. Louis Publisher : Living Videotext, 2432 Charleston Road, Mountain View, CA 94043 (telephone: 415-964-6300) Materials: One copy-protected diskette, 64-page bound manual with index, three months diskette warranty, $30 to replace diskette during the following twelve months. Price: $195 Machine Specificity: IBM PC and 100%

ThinkTank is used to create and manipulate outlines of headings and sub-headings. Elementary features common to word processors, database managers, and screen editors are combined in a single package.

The Effects of Modes on Text Editing by Experienced Editor Users

Experienced nonclerical users of two screen editors, vi and emacs, were asked to do a series of editing and composition tasks. The results suggest that moded editing, as exemplified by the vi editor, may be preferable far fixed editing tasks, whereas modeless editing, as exemplified by the emacs editor, may have some advantages during composing. The vi subjects left fewer errors in their final files and showed a tendency to do the editing tasks faster, though the time differences may have resulted from differences in typing rates. They made few mode errors, and those few were rapidly and easily corrected. The emacs subjects tended to do more of their editing during the first-draft stage of composing than did the vi subjects; this result agrees with the hypothesis that modeless editing is more flexible than moded editing. However, the total editing done while composing, the composing time, and most writing-style variables were similar far the two groups.

Design of a simple screen editor

AbstractThis paper describes a simple screen editor, which could be implemented fairly easily on most interactive computer systems. A screen editor shows whole pages of text on a video display terminal; text is modified by moving the cursor and overtyping mistakes. Screen editors are significantly more pleasant to use than conventional (hard copy) editors for most editing tasks. In this paper, one editor is described in some detail, then design goals and implementation problems for all editors of this type are discussed.