LUMIERA.clone/doc/design/gui/GuiDiscussion/archive/rawGuiBrainstorming.moinmoin

#acl all:read
## page was renamed from Cinelerra3/GuiBrainstorming
## asciidoced by brunology. Please notify brunologyATgmxDOTcom if you edit it.

## This is a backup copy taken by Ichthyo from the original (unreviewed) GuiBrainstorming page 11/2010
## Somehow I can't find this original page, but according to the above comment, it should have been asciidoced
## I'm storing this backup, because this original page still contains a wealth of ideas, even if we won't have
## the standing to cope with them right now



= State of the GUI =
attachment:Lumiera/GuiBrainstorming/screenshot090418.jpg

Updated 18/04/09

= About this Page =
We accumulated a lot ideas here, but over time this became a big mess.
The first step was  to move content of this page to ["Lumiera/GuiBrainstormingReviewed"] in order to be sorted out by the developers (please do not edit there when you are not a developer).

Recently, the content of this page was ASCIIdoced together with other relevant content of Pipawiki and will be included in the Lumiera documentation tree which is currently being built up. Meanwhile, if you have any interesting/thrilling/urgent new ideas, you should just post to the Lumiera mailinglist.

----

=== Media Management and GUI ===

Do you plan to include Media Management? 

I like Apple Shake GUI - simple and with node based workflow. Shake also allows to see final composition on second monitor, which is good for those with dual screens.

For GUI inspiration you can also look at Autodesk Smoke (the best all in one video software for linux)

http://download.autodesk.com/us/mnevideo/SF_mit_demo_900k.wmv

or more here:

http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=5601211&linkID=5572506


 . -- ["ct"] [[DateTime(2008-07-22T06:42:26Z)]]

= Some must-read articles on usability in the UI =
http://download.blender.org/documentation/bc2008/evolution_of_blenders_ui.pdf This is an excellent paper published by Blender developers that covers the pros and cons in the current Blender interface. It is an excellent example of a UI for complex, multi-layered programs. Blender is a great example overall of what we are trying to accomplish - I would love to have Lumiera be the Blender of Video Editing as the most stable, full featured, intuitive, and supported app out there, with all the threads of Video Editing built in. This includes

 * Directed acyclic graphs to manage effects.(http://tinyurl.com/63cb7o)
 * All parts of the Editing process included in the program: (1)pre-production work like importing and capturing, (2)video effects as simple as color correction or as deep as Apple Motion's, (3) Audio remastering (4)timeline and transition editing, and (5)exporting, including a DVD menu editor/burner.
 * Full integration of keyboard shortcuts that are kept consistent throughout the program.
 * The splitscreen workflow that blender integrates. Take a look at some videos of Blender designers using the program and see how efficient their workflow is because of this.
 * All other points outlined in the article.
http://www.asktog.com/basics/firstPrinciples.html Whoever wrote this knows what he is talking about. He gives very complete points on all aspects of UI usablilty and how that translates to user efficiency. Any UI designer needs to study this.

 . http://www.asktog.com/columns/022DesignedToGiveFitts.html This is a good article on Fitts's law, written by the same guy as above. A general rule of thumb is that if it doesn't fit with Fitts's, it should be thrown out.

'''Another suggestion'''
Feb. 4, 2009.

I am also a video editor and I wanted to criticize some of the features of the current GUI.

First is efficiency of space. There is a lot of dead space in the current design, noticeably below and above the timeline. Also, above the viewer. The layout isn't very efficient. Most of my editing is done on a laptop because I am on the go. Screen real estate is at a premium. I would love a dual monitor display, but I don't have that luxury. In this same vein, the timeline window is too "fat." The representations of the clips do not need to be that large. I am often layering many many many clips and scrolling up and down on my touchpad takes a lot of time. All I need is representational rectangles about the height of my cursor. That being said, I like the idea you have begun to implement of minimizing and expanding bins of tracks. That is a great idea and will help the editor organizationally.

Second, I need the ability to cut my clips. I think that you can replace the text cursor button with this. I will not use the cursor button. There should also be a button to bind tracks together and link them (and to unlink them). Also there is no volume meter so that I can see audio levels.

A question: where will I edit the settings for my effects and transitions? Also, I think that where you are going with the integration of a clip preview and compositing window is a good idea. I don't use them both at the same time.

Next, this isn't a high priority, but I liked the idea on the mailing list which allowed you to choose which layers were displayed in the compositing window via drop down menu right below the previewer. This could be done like a check list where each layer bin and sublayer is shown. You select/deselect those to be shown.

Also, this is more of a programming feature, but I think it is necessary to allow "bezier curve" editing for the audio/video clips. I don't know the proper terminology, but Final Cut Pro allows you to use a Pen tool to adjust the volume/opacity of the clips like in a vector program. I find this incredibly handy when I need to do quick and dirty fixes and don't want to do heavy-duty sound editing in another program.

To conclude:

Please think about maximizing efficiency when it comes to screen real estate. The current mock-up wastes a lot of precious pixels.
I love the idea of 'layer bins' that expand and collapse
We need a audio level monitor. It doesn't have to be too big.
Integration of clip preview/compositing window may be a winner, b/c it conserves real estate and are not used at the same time.
We need a few more tools.

Best,
Yanik

-----------------


'''Just a suggestion'''

I´m also a video editor, and in my experience, I can suggest that you take a look at Canopus Edius, Premiere Pro, and Final Cut GUIs.

Although they have significant differencies related to their respective playing and rendering power, they have a  similar approach in respect to editing tools and interface. In fact, any of the three has a far better and more versatile workflow than any of the Avid Suites, and it is due to the old concept used in the Avid timeline, that makes it inefficent and time consuming, something that can not be afforded by the video editor which is always under timeframe pressure.

I really hope that you succeed with this project, it would be a grat improvement for the video editing community.

Greetings


'''One other suggestion''':

Please. If you want conclude a professional video-editor, forget all "amateur brands" and keep focus in Avid and Final Cut (maybe Autodesk Smoke too). Let's study the work interface, the capacity to manage a big big project with thousands of files and too the correct management for import and export media.
Please hear the professional editors and forget the homemade weekend video-amateurs.
[[BR]]Grets
 . rest assured that we embrace to follow exactly this course: big project, lots of footage, craftsmen at work. (But we don't limit ourselves to professional users alone, interested amateurs and semi-professionals should feel at home to.)
 . -- ["Ichthyostega"] [[DateTime(2009-05-28T19:18:46Z)]]
 


= PLEASE keep focused! =
I am a professional editor, not a programmer. So understand the joy it must be for you guys to built 3d Effect System things, Multilayer Compositing Stuff, Tracking Algorithms etc. But honestly, you should decide what you want to do. There is After Effects, Combustion, Flame, Inferno, Shake and a lot of others in the compositing league. There is mainly Final Cut and Avid in professional editing, with little competition from Premiere, Avid (ex Pinnacle Liquid) and Quantel SQEdit. Personally i think what Linux needs as a starter is not a does-it-all editing/compositing application, but a well thought editing program. Cinelerra does not fit this description. Kino does not fit this description. Neither do i think that Linux needs a program like Windows Moviemaker, nor iMovie. These are for hobbyists and Kino is almost there and Cinelerra could be there if they reduced the featureset. When i look at the GUI suggestions here, it gives me the creeps. Did you people ever take a look at at Final Cut Pro, Avid Mediacomposer or Quantel SQEdit? They look MUCH MUCH cleaner and less cluttered than any of the suggestions here.

Why? As an editor the toughest part of your job is to know the material your working with, sometimes hundreds or thousands of clips, material that totals from 5 minutes (for a news show) up to hundreds of hours (for a long documentary  film). You need make notes about the quality of the shots, select and order them in a way that suits the presentation, i.e. in an artistical or informative manner.  The job of an editor is to know about the footage he is working with. The editing program is a tool, and not an entertainment center. The hard part of the process is the film you are working on, so the program that enable you doing this should as minimalistic as possible giving you an EASY access to the things you need. What do you need for your work? Your footage and your timeline. And a place where these things can be played back.

In approx. 80% of all edited TV footage there is not single effects used. Television stations have graphic departments, that design and create packaging for TV shows, in Film there are motion graphic designers that provide the graphic elements. And even at home, for your low budget independent movie, you can use Blender, Quartzcomposer, Gimp or whatever to create effects and graphics export them with an alpha key and apply them to your film. So why do programmers in Linux always focuse on Effects? Believe me, this is NOT important to start with.

I never saw a Linux editing program that could do the very basics: - Accuracy, as the most important: Never loose a frame not during capturing and not during playback. Not a single frame. Always run EXACTLY at the set framerate, NEVER have to speed up or slow down.  Never roll to an approximate timecode always THE EXACT Timecode. Never loose Mediafiles, never loose project files, never corrupt a project file etc. - Digitize from various sources, using timecode controlled VCR Decks. You need to support at least a basic range of Hardware IO Cards, so the you can ingest SDI, Component Video, Firewire etc. Look at the Stuff Blackmagic Design / Decklink is selling, these a reasonable professional and affordable IO Cards... - Handle Timecode correctly, easy? NO! 25fps, 24fps, 29,97 fps, 30fps, DropFrame / Non Drop Frame etc. - Handle 8 Tracks (standard) of Audio correctly, always keep it 100% in sync. - Support industry standard Import/Export Formats. The basics: AAF / OMF, various EDL types... - Think about a container format for the Video, OMFi, MXF...

Whatever else you do, if you dont have this stuff, there is NO chance you will ever have a professional editing software. I know these points sound really boring and probably you want to go for another iMovie, but then i dont understand why you dont help the people from Kino etc.

So as for the GUI: You need a Clip Window, a playback Window, a Sequence Window and a Timeline. Thats it. I prefer the "dualview" concept which is standard in Avid, where the playback window is always left and in the same size as the sequence window and most of my collegues do. Some people like floating clips (where the playback can be positioned but i think thats a secondary problem. Personally i think A/B Editing layout (where you need two video layers to apply a dissolve) is a thing from the past, i think even premiere dropped this concept. Video dissolves are applied in the same way as a audio dissolves. Dont focus on rubberband (aka keyframed) audio or effect levels, with 8 audio tracks and timepressure, there is no way that you can fiddle around in a microscopic timeline.

cheers tilllt attt yahoo dott com

 . Hi tilllt,[[BR]] what you wrote are mostly our ideals too. Our reasoning was that Linux is lacking just such an application for the core video/film editing task. The page  here is for ''GUI brainstorming'' and collecting of ideas and may give you a wrong impression of the overall vision of Lumiera. Film editing is an minimalisitc art, the challenge is to create something convincing by using "almost" no ingredients. But, there is one important limitation to be aware of. As an open source project, we rely on people contributing because they find it interesting and challenging. Thus, we need to be open for extensions, maybe common ones, maybe wired and unconventional ones. Thus, our approach is to start with a very solid engine core -- and yes, it ''absolutely'' needs to be 100% precise. We won't accept a "it doesn't matter", or "you can't see/hear the difference". Timing should be as precise as possible, data handling should be done "state of the art". Besides that, the most important thing is modularity, thus providing clean extension points where people could bring in any plugins or extensions they find thrilling, while other people (like myself) should have the option to create a session setup with just the small number of tools they need for their work. In a similar vein, Joel, our core GUI developer cares much for keeping the GUI clean and uncluttered.
  . -- ["Ichthyostega"] [[DateTime(2008-08-20T22:28:35Z)]]

   . "Clean and uncluttered" for whom? It very much depends on who your designing an interface for. n00bs want one thing, pros want another. There's no magic UI for both.
   . -- ["MetalMusicAddict"] [[DateTime]]

= Global GUI Ideas =
== Screen concept ==
 * Multi server
  . Display GUI components on different Xservers, some critical components (GL rendering etc) might be only supported on local displays
 * Multi Head
  . Can open Windows on different heads of the same server, and is aware of the existence of different physical monitors (ie. Xinerama-aware)
 * Tiled Windows
  . One Window can be tiled (horizontally/vertically) giving areas where screen elements can be placed (see blender)
 * Multiple windows
  . Can open multiple windows on one head and (optionally) tile them as above
 * Fullscreen Support
  . Windows can be made fullscreen with no decorations (but tiling left intact)
  * Widget overlay/Fullscreen
  . Some Widgets can be made half transparent and overlay video giving a head up display editing while the video is at native resolution in background.
   . Window configurations can be stored/restored in customizable presets and are part of the project (see blender again)
 . -- ["ct"] [[DateTime(2008-02-07T20:42:54Z)]]
 * SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compositor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency blurring and the ability to interpolate these events over time...things that can be incorporated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better. -- jb [[DateTime(timestamp)]]
= Global System Structure =
 * Client / Server Model
  . The server process will act as the master coordinator for the system, and will accept input from multiple GUI clients, and dictate tasks to multiple slave processes (even on separate physical servers). The GUI client application could be multi-platform. File transfer and communication could take place over SSH and make use of SVN for project management. Proxy editing will be the norm, due to the higher resolutions of final videos (the RED Epic will handle 5K). The entire system could easily work on a single Linux workstation, for easy adaptability from handling home videos to expand to editing cinema films (which could benefit from dedicated GUIs to handle video, sound, etc.).
## -- ["ct"] [[DateTime(2008-05-21T13:46:51Z)]]  hey who putz my signature here? the above tex was not from me! :P
----
= Sparse Timeline =
Make the timeline view ''sparse'', that means the time on top is not continuous anymore but 'boring' sequences get omitted and 'interesting' sequences get displayed, probably even stretched to cover at least a single thumbnail.

This needs an ui (menu or whatever) to turn this feature on and some selection which events the user is interested in (scene cuts, transitions begin/end/mids, keyframes (begin/mid), labels, ...)

 . -- ["ct"] [[DateTime(2008-05-21T13:46:51Z)]]
 . (name? and time?)
'''"Sparse Timeline" is in Trackview '''- see Track view section lower down the page

This is the kind of features I have suggested in the Trackview section lower down the page. I like the name you give it - "Sparse" because it allows the user to not have to bother viewing OR scrolling past all the stuff in between two end points (or more items) just to tweak the ends of a segment. But I would emphasise that instead of reducing the width of the timeline because of the narrow time span needs for the one task, that more tasks can be carried out in the same view. This is because the view just misses out all the stuff in between, for each task.

I am playing around with a few thoughts and maybe might attach an image of how it might work. But in conjunction with "tabbed views" it would result in the convenient ability to display all the work areas in a concentrated display, meaning a whole lot less scrolling around, and clicking to bring windows to the foreground.

 . -- ["Tree"][[DateTime(2008-05-23T16:59:00NZ)]]
'''"Contracted Timeline" just shows transitions, and option to display anything that has effects that alter more than "X"% between transitions'''

The main aim of this timeline view mode, is to '''''just show the transitions'''''. The scene content is reasonably confident as being what is needed, especially if it has been made with clips that were pre-edited before being added to the multitrack project. The normal part of the scene gets completely skipped over.

In the case where effects are used, then this same system can be used to check the "gross" result, by''''' checking the timespans where the effects cut in and out'''''. These time locations could be detected by a variation of the effect setting of more than "X"% per unit time.

. -- ["Tree"][[DateTime(2008-09-08T23:30:00NZ)]]

----

= Clip Mode =
This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. -- ["rexbron"]

== Rational ==
The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together.

 . (name? and time?)
----
= Scrolling with the mouse =
There is a subpage just for this topic as this should be a very wide problem. Please see http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming/scrolling for details.

----
= Inspiration =
=== In the best-of-professional-competing-products department some material for case studies: ===
 * Comparison between Avid and FCP from a couple of year ago: [http://www.fini.tv/articles/avidfcp2006.html at fini.tv]
 * There are more interesting articles comparing FCP and Avid on Scott Simmons [http://www.scottsimmons.tv/blog/the-avid-vs-fcp-articles/ blog]
  . but the server was down during time of writing, so more links soon...
 * Check out Kdenlive. The project appears dead in the water but the GUI was EXTREMELY sensable and easy to use. Any window could be popped out, full screened, and some of the tools were interesting like a "slice-all" and a "move everything right of the cursor" control.
 * It may well be worth borrowing some of the UI innovations from[http://www.newtek.com/speededit/ NewTek's SpeedEDIT].  For a rough edit, some of their features look to be incredible time savers. http://digitalcontentproducer.com/videoedsys/revfeat/705DCP_ErevSpeedEDIT2.jpg
 * Here are two super interesting tutorials for discrete Smoke, high end NLE that runs on Linux:
  . A detailed flash tour through the [http://download.autodesk.com/us/smoke2008uitour/index.htm User Interface]
  . An in depth tutorial (about an hour) showing the workflow and the different [http://download.autodesk.com/us/smoke_training/Smoke2008_GS_vid_tutorials/ modules]
  . And here is a good tutorial how to actually do editing on the app. Shows clearly [http://download.autodesk.com/us/smoke/video/Smoke2007_Primer_movies/index.html how it works]
 . -- ["sakalli"] [[DateTime(2008-04-10T22:00:29)]]
=== More Ideas ===
 * Ton(Blender creator) in an interview about the future of blender. [http://www.blendernation.com/2008/02/18/the-future-of-blender/ video]
 * http://gimp-brainstorm blog spot com/ Gimp UI Brainstorm
= Sketches/Drafts =
Some people contributed drafts/sketches/ideas/brainstorming...

 * AkhiL proposed to do wiring of '''Nodes''' within the timeline: [:Lumiera/GuiBrainstorming/Proposal.AkhiL:see here]
 * Richard Spindler (oracle) proposed a '''Node Graph''' approach together with a "Scratch Bus" and Meta-Clips: [:Lumiera/GuiBrainstorming/Proposal.RichardSpindler:see here]
 * Hermann Vosseler (ichthyo) explained some of the possibilities of the '''Proc layer''' and based a [http://ichthyostega.de/cin3/drafts/GUI-draft1.html GUI proposal] on them
 * ["alcarinque"] has an idea about defining the '''gui''' in '''different modules'''.[http://telniratha.atspace.com/spec.html see here] Feedback appreciated.
 * Pablo Lizardo made a mockup for the timeline based in the Cinelerra UI elements.[http://farm4.static.flickr.com/3067/3003432151_e30258be3e_o.png see here] .
== Toward a Concrete Sketch ==
See this sketch [attachment:GtkGUI-0.1.png attachment:GtkGUI-0.1.png]

The sketch is certainly not complete by any means - this is a v0.1. There are many Avid and Cinelerra features that ought to feature in the final product. However it shows a few ideas that I think would be good.

 * My personal preference would be to produce the GUI in C++ with Gtkmm. Gnome is the most popular desktop for Linux, and GTK now has good support both for Win32, Mac and KDE (except that GTK on Mac still needs X11, probably for some more time)
 * IMHO it's much better to make an interface out of standard bits (controls, fonts, colours) wherever possible. We really want to make Linierra "like other apps", rather than making our own unique GUI elements just for this project - the way Cinelerra does. This makes it quicker for new users to begin work, and feel comfortable.
 * This sketch shows the GTK docking system, as seen in Anjuta (and to some extent in Inkscape). The GTK docking system is like a tiling window manager in a window. This allows the layout of panels to be totally rearranged, or even detached into floating windows. These floating panels can be stuck together in a single child window. This would be a perfect way to span the workflow across 2 screens. For me, it's this feature that most attracts me to GTK.
 * The sketch shows a few very preliminary ideas for where the menu/toolbar commands should be located. These will likely change quite a bit though.
 * Stealing ideas from Windows Movie Maker, it seems better to display transitions and filters in a way that shows the user what the filter will ''do'' to the video/audio, rather than using metaphors: like George Bush=Unsharp in Cinelerra.
 * Tango style icons mean the Luminierra will look consistent with Gnome, Windows, Mac and KDE - and the rest of the free desktop applications.
My final word on the subject is this "Attention to detail: it matters!" -- JoelHoldsworth [[DateTime(2008-04-03T20:09:34Z)]]

== Tango desktop Project - useful for skinning palettes and icons ==
Tango Desktop Project aims to provide a consistent user experience for applications on different free and open-source desktop environments. The key objective of the project is to allow developers to easily integrate their software (in terms of appearance) with the desktop. The visual inconsistencies that arise from different desktop environments (KDE, GNOME, Xfce...) and custom distributions make it hard for third parties to target Linux. A common misconception is that the project aims to provide an icon theme that works across the major desktop environments (like Bluecurve).

http://en.wikipedia.org/wiki/Tango_Desktop_Project

Franco Iacomella has started a project to use Tango to create a new GUI for Cinelerra, which he would also like to contribute to Lumiera.

http://francoiacomella.org/proyectos/tangolerra/doku.php?id=start

http://francoiacomella.org/proyectos/tangolerra/lib/exe/fetch.php?cache=cache&media=screen-1.png

The pallette feature of Tango may make it fairly easy to have a range of colour based themes, using a similar icon set. So at least folks who want a background colour other than "darkroom black" have some sort of choice. 

--["Tree"][[DateTime(2009-01-31T14:43:00NZ)]] .

=== Alcarinque's Gui Design ===
[:alcarinque/concept:Concept ideas for Lumiera]

[:alcarinque/gui:Alcarinque's Gui Design]

=== rcbarnes's (a.k.a. Clay's) Gui Design ===
 * Discussed in part in the IRC channel
 * Sketches posted in a [http://www.hci-matters.com/blog/2008/05/21/lumiera-timeline-first-draft/ New Interface Advocate Entry]
 * Copying comments and thoughts into the reply box there is highly appreciated, so I can keep track of them easier!
= Widgets =
== 3x3 Menus ==
Have a mostly quadratic 3x3 dialpad like popup menu poping up so that the center is the mouse position (adjusted when near screen corners). The middle field is always the close/cancel functionality and the 8 fields around offer the menu entries. Navigation can be done by mouse, cursor keys or numpad! Menu entries can open 3x3 submenus again, either incremental so that closing brings you up to the higher menu or exclusive that closing aborts the whole menu.

 . -- ["ct"] [[DateTime(2008-02-07T20:42:54Z)]]
== Navigation Systems ==
There may be several methods to make menu selections, and other choices. The Gui could be made quite adaptable/customisable. Using a "skin" approach to the Gui, would provide a system for users who are not programmers, to help develop improved user interfaces. Mouse "gestures" (may be patent considerations) are another option. The way that options are communicated with the program functions could be made so that even as yet undesigned "user chooser systems" can be added.

 * -- ["Tree"] [[DateTime(2008-05-14T08:40:00NZ)]]
== Generalized Fader ==
attachment:fader.png

All faders are the same kind of custom widget, that is:

 * a slider to adjust the value with the mouse
 * a level indicator (progress bar?) reflecting the actual level of the signal
 * a spinbutton/text entry to add a value with the keyboard
 * a label showing the measurement unit and other information
 * a popup menu to configure this widget itself
  * enable/disable the things above
  * set start and end values (the application gives an absolute allowed range)
  * change the measurement unit (byte, percent, dB, ...)
  * change between linear/logarithmic behavior
  * snap at specific intervals
  * horizontal/vertical slider/level
 * adaptive scroll wheel (see below)
for the application all faders provide a float (or double) value, nothing else.

 . -- ["ct"] [[DateTime(2008-02-07T20:42:54Z)]]
== Magnifying Glass for the Faders ==
Faders should have a "magnifying glass" mode, which can be activated by a key combination or modifier key. When activated, you can fine tune the current value: The step increment is lowered ideally to the real limit of the underlaying parameter, or, if this is too much, at least it should be much smaller than anything you get by dividing the possible value range by the fader length in  screen pixels. In this mode, the fader doesn't cover the whole range, rather it is centered at the current value. Changing the value by these small increments should give an obvious visible feedback. Ideally, an accompanying automation curve display will switch to the extreme vertical zoom as well. And it's important that you don't have to zoom, you enter/leave with one keypress.

Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when working with sound, the problem is that the parameter range cover several orders of magnitude. For example, even 16bit PCM sound has a volume parameter which can be adjusted in 32768 steps, and yes, there are situations when these fine steps make an audible difference, while most software faders give you not much more then a view hundred subdivisions even under optimal circumstances.

 . -- ["Ichthyostega"] [[DateTime(2008-02-07T22:34:08Z)]]
This concept of "magnifying faders", is well explained in [http://thorwil.wordpress.com/2007/05/01/fan-sliders/ Thorsten Wilms Fan-sliders Article], the Article also links to an implementation.

 . -- ["oracle2025"] [[DateTime(2008-02-08T00:40:05Z)]]
 .
== Widget to carry out adjustments at fine resolution within trackview - all controls immediately at hand ("cross-hairs"). ==
An example of this widget is shown in two of the trackviews further on down below.

Have you ever seen a magnifying glass with a torch built in? A toolbox version of what the doctor uses to look in your ear.

This has the convenience that you do not have to reach for a torch while holding the magnifying glass. The added benefit of this is that everything is close at hand. (so bringing this concept to the current situation) A lot of editing that gets done, requires long distance mouse travels, from track selections, point selections, menu selections, clicks and slides. The issue is not just the distances traveled, but also that these items need to be kept within view, and distract the concentration 'away" from the material being edited. The objective of this widget is to provide local resolution on a section of track being edited. It can slide along the track. Many of them can be used, and left on the track''''' "attached" to the locations they are left at''''''''''''''''''''''''''''', acting like''''' bookmarks for edit points''''' that remember the settings for the kind of edit being done (not yet completed - or done but need to remember what was done).

All the controls are built around the side(s)(perimeter) of the (magnifying) viewer - so the travel distances are very short, and high mouse sensitivity can be used - mouse sensitivity can be automatically increased within the view area (and slightly outside the view area for a short delay time). Sliders can be adjusted by mouse, but also keys. You will see that keys chosen are in pairs which may be easy to remember, because of their convenient location on the keyboard for both left band right hands -'''''qw, as,zx (left) and op, kl,nm (right)''''''''''''''''''''''''''''', these''''' key pairs'''''''''''''''''''''''''''''can be used for''''' on the fly adjustment of multiple parameters'''''. The adjustment could be for more or less - either by a fixed increment each time clicked, or by increased amount the longer held down.

The layout of the keys make sit very easy to move both hands up and down the keyboard, choosing more and less. In the first pass of '''''live adjustments''''', they may not give perfect results, but they certainly make it plain to the user, what it was they were wanting to do, when they return to edit the strip later (in non-linear static time mode). Other toggle/mode of use buttons can be built into the tool. Local "preview"-er can be attached and be of any size. Transition and effects selector can also be attached, if wanted in the set-up set. The user could select actions (buttons/purposes of sliders) to be included in the tool's perimeter, and save the setup (gets named - and can determine what situations it gets used as the assumed default set-up to use) for future re-use. Some attached tools like previewer and resources could be set to minimise when the mouse is moved away from the locality of the tool.

attachment:Screenshot-Cinelerra_trackview-crosshairs_widget_01.jpg

Widgets can be'''''"connected" in their influence''''', so that adjustments made in one widget are also made (and maybe scaled) in other "connected" widgets at other locations. Edits made within widgets can be saved and re-applied at later times in other places and projects (just another way to collect input data similar to the use of "undo"/macro feature). The track/thumbnail height and width within the magnifier may be increased, and toggeld/switched between levels of magnification.

''A note on Gui''

 * Any tool or option, which is not currently in view, is going to be at least 2 clicks to get selected.
 * Any tool or option which is not in view, will be easily found if it is in an obvious and easy to understand step of choice to access.
 . --["Tree"][[DateTime(2008-09-05T10:08:00NZ)]]

== Trackview Timeline Widget option ==

The timeline currently shows the bar as a percentage of the total project time, and sliding motion is linear over the whole project time. So as the project size grows, the bar gets shorter, and the timespan covered by mouse motion increases - i.e. the same mouse motion moves faster through the movie for larger projects. This makes it difficult to get to exact locations when the project time is large. 

There needs to be some way to get finer movement when nearing the desired point of editing. 

One option is to have a second (or third) timeline that shows a subsegment of the main timeline. The main project timeline can be below the subsegment timeline. The subsegment time span can be shown on the main project timeline. Finer movements can be made in the subsection timeline. For really large projects, a third sub-subsection timeline can be shown above these. 

Options for referencing subsections might be by labels, chapters, or scenes, or custom begin/ends. The method of referencing the subsection, can be chosen from a drop down menu to the left of the respective timeline (in the row titles area).  Labels, scenes, chapters and begin/ends can be defined for use on the timeline.

The subsegment timelines can have "jump to" next, before or "go to" buttons, to make it easy to go straight to other subsegments, without having to manually reposition the edit zones.

The subsegment timelines can be toggled into/out of display using the standard rotating triangle button.

 * -- ["Tree"] [[DateTime(2008-12-27T11:58:00NZ)]]

== Use an existing widget/windowing toolkit ==
Lumiera should definitely use an existing toolkit, instead of drawing widgets manually. I suggest either QT 4/KDE 4, or GTKmm, for many of the reasons of JoelHoldsWorth above.

 * Existing widget systems are already ported to various operating systems and blend with them (to varying degrees, QT is better in that regard).
 * Both QT and GTK provide accessibility features that take extensive time to implement from scratch.
 * Both can blend with the host OS, or be easily themed if the users wishes to.
 * An extensive array of widgets are already provided, and easily expandable if none provide what Luminera needs.
 * Both support SVG, as well as procedural rendering of vector graphics, Cairo in GTK and QTVector in QT.
 * Both respect native fonts, and use antialiasing and possibly subpixel rendering to draw graphics. -- TD-Linux
== Node System ==
I propose an assembly system where the source material is left untouched where effects are added one the fly similar to html and dtp packages. In this system the system is linked together using an node system similar to gstreamer and jack.

=== 3 dimensions ===
 * Time
 * Tracks (sources)
 * Modifiers (pipeline)
=== Key driven ===
A good entry level gui together with an advanced key driven system like about blender (not so much the ui)

=== Video desktop ===
The video editing is software is best seen as an extension to the desktop. e.g: dropping a video in the work area would immediately create an input node.

Pro:

 * I believe that this far more performant than the background rendering system of cinelerra, look with how much ease you can add effects in xine (certainly much faster than cinelerra).
 * Storage is a real issue in video editing certainly with high res content.
 * Greater flexibility (plugins system, other sources, possibility to have multiple outputs)
 * All idea's presented on this page could be implemented with such system
 * Possible to use external systems (e.g: xine as output, dvgrab as input, etc).
Contra:

 * Total different than traditional approach, basically no more tracks on timeline view
 * Maybe out-of-reach, to much work to realize soon
 . -- ["philip"] [[DateTime(2008-06-17T22:22:54Z)]]
PS: always consider the consequences of your decisions and priorities (personal experience, example: client/server which is hard and doesn't deliver alot of benefits).

== Widgets in keeping with other Video Editors and standard GUI elements ==
The GUI review page at http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstormingReviewed, says ;

"We really want to make Lumierra "like other apps", rather than making our own unique GUI elements just for this project - the way Cinelerra does. This makes it quicker for new users to begin work, and feel comfortable."

This is good, because of familiarity. But familiarity can only exist if there are suitable widgets already in existence. In the case where new widgets are needed, then this consideration should not stop them from being developed (there has to be a "first" time).

When a new widget is being newly created it might be helpful to consult other potential users/implementers (in this case video editors) to get some opinions and input from them. Where a widget is a composition of other parts, then already available parts could be included, and the "styling" (e.g. Tango) of new parts kept similar to established parts (e.g. borders, toning, corners).

By all means, do not hold up development because of not wanting to make "our own unique GUI elements just for This project" . The widgets can be made and shared with a number of other projects also - may be those projects might like to make them instead, or at least help.

 . --["Tree"][[DateTime(2008-09-05T21:48:00NZ)]]
== Edge view Wheel Widget for incremental time advance rather than percentage. ==
This widget allows for linear time advance. It looks like a wheel with a serrated edge, laid on its side, with the edge exposed in a horizontal (or vertical) slot in a panel.

This can be mouse wheeled on, or dragged, or it moves when arrow keys are pressed.

Anywhere where speed, or advance is controlled by a slider/joggler, there can be a toggle between slider and wheel modes. This way, the user has a choice between large jumps, and finer movement.

 . --["Tree"][[DateTime(2008-09-08T17:47:00NZ)]]
== Node Editing system in Open Movie Editor - example ==
Open Movie Editor also has a node editing feature which can be seen on the OME screenshots page http://www.openmovieeditor.org/screenshots.html http://www.openmovieeditor.org/nodefilters.html

http://www.openmovieeditor.org/images/screenshots/node_editor_thumb.png

--["Tree"][[DateTime(2008-08-25T19:22:00NZ)]]

== Node Editing system in Mewa Film ==
Mewa Film has a spacious GUI for node design. The example picture is possibly a simplistic example compared to more demanding use. It has notable features including "before" and "after" views, and panel of sliders for adjusting paramters. This kind of presentation could be made available within Lumiera as a tabbed view.
http://www.mewatools.com/index.html

http://www.mewatools.com/images/nodegraph_mainwindow.png

--["Tree"][[DateTime(2009-01-31T00:16:00NZ)]]
----

== Adaptive Mouse Wheel ==
most numeric value entries (sliders, spinbuttons) can be changed when hovering the mouse over it and turn the scroll wheel (maybe with an additional modifier key?) -- The scroll wheel is accelerated depending on how fast it is operated by the user, snapping it slowly gives frame/interval precise increments, turning it faster will exponentially increases the increment (2,4,8.. frames per click)

 . -- ["ct"] [[DateTime(2008-02-07T20:42:54Z)]]
== Work well with tiling window managers ==
I propose that the future Lumiera GUI is designed without too much (or anything) about the user's screen apart from what is acceptable based on the X11 protocol(?) in order to work well with tiling window managers. The main problem to watch out for is assuming specific dimensions. The nature of tiling window managers is that most of the time, the windows without focus are dramatically downsized in one or two dimensions. This causes poorly designed GUIs to behave strangely, sometimes as bad as constantly jumping between layouts and thus causing unnecessary CPU load.

 . -- MichaelPloujnikov [[DateTime(2008-04-14T22:29:12Z)]]
== (easy?) Installation Method for having many versions installed ==
A method that allows the user to have more than one version installed means that the user can have a reliable version, an unstable version, and some older versions all ready to run. This ease would encourage the installation of variants, because it does not force the abandoning of an already familiar version.

An extension of this feature, is to permit the mix and matching of various components between the versions. So a person can opt to use an unstable version of one component, while keeping stable components for their main work flow. If they can "live switch/incorporate/eject" the components then they can easily revert or upgrade their components and can test them under very similar circumstances.

An additional option is to enable side by side comparisons in the work flow typically used by the user. This approach would allow the user to select more than one version of a component to use and the order that they will be used in. The user can rate the comparative ease of the interface. The speed and performance of the software can be measured on the machine. Lessons can be learnt, and settings that depend on machinery can be tuned (i.e. recommendations for settings to be used on types of equipment).

 . --["Tree"][[DateTime(2008-05-14T00:54:00NZ)]] *
== GUI development - flexible approach - using "Skin Methods" ==
In developing a GUI, the approach would normally be for the developers to design the Gui as the project progresses, and it comes out at the end. This is not bad, especially as there is a GUI to be had. But if there is a desire (which there appears to be a healthy desire here) to try new things, and look at options, then it would be quite useful to have a development method that allows for experimentation with options, side by side comparisons and assessments. Assessments by '''users''' and developers.

GUI design could be available for release for whoever wants to do a spin-off project re-GUI. So a GUI gets made by default by the development team, but the '''skin kit''', and '''methods of activating/interaction with the "engine"''' are made available. Users can then run their own tests and some sort of concensus arrived at later as to what is considered to work well, in what sorts of different user situations (newbie, small, large/expert).

If there is vibrant enthusiasm for teams to work on (alternative) GUI(s), then the developers may even avoid the need to do much of the work on GUI, and just announce what the interface requirements are - the (choices of ) GUIs for some sections could be ready '''''before the program is finished'''''''''''''''''''''''''''''. The '''''GUIs could be discussed and developed  ''''''''concurrently''' (even '''''in advance '''''of) the respective program code. On the other hand the GUIs could lag behind the development of the engine, but not hold the engine up. Some GUI groups could be ahead of others in some parts of the program and behind in others - the user could even choose to use the GUI (widget appearance) from one theme for one part of the interface, and GUI from another theme for other parts.

There could be agreement between GUI teams working on different themes, to cover separate parts of the interface first, so that there is at least some type of theme for the GUI for the whole program ASAP. This helps get a GUI up and running so users can trial both the GUI and the engine. As use (and time) progresses, the trialling will help determine what adjustments are needed for the GUI, while at the same time allow more extensive testing and debugging of the engine.

The engine is likely to be in use for many years to come, due to the excellence and diligence used in its creation. Good software code takes a long time to age. But the styles of user interfaces are always on the move. e..g. the brushed metallic look, the bright colored plasticy looking rounded buttons and panels, the corporate gray with square corners, and others. Skinning allows the program to take on fresh appearances that help the general user "feel" better about the "new look" program. The user can tune the program appearance to their preferences (which may be disability related). Being able to keep the style looking up to date will mean that Lumiera will be far less likely to appear "vintage" on an organization's desktop.

--["Tree"] [[DateTime(2008-06-05T20:33:00NZ)]]

== Branding ==
A novelty feature would be to allow the user to place their logo /and/or (organization) name somewhere in the program's window. May be the top title line on the right just in from the x/max/min buttons. But larger logo may be placed in a vacant space somewhere further down.

 . --["Tree"][[DateTime(2008-09-09T09:03:00NZ)]]
----
= Physical Control Devices Interfaces =
See http://pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview

The Physical Hardware HID-UI could be shown next to GUI with an arrow pointing to the GUI.

== Support MIDI controllers ==
Similar to Ardour, Lumiera should support the increasingly popular MIDI controllers / control surfaces. You should be able to bind any fader to  any hardware knob or fader of the controller (maybe similar as Ardour does: there you ctrl-middle-click to the control on screen and then move/touch the hardware fader to automatically learn the emitted MIDI message). Having dedicated Knobs, toggles and faders with motorized parameter feedback makes for much more tactile working.

 * maybe you could even have an auto-association to bind one special fader always to the "current property" (similar as the mouse hovering
  . combined with the mouse wheel does
 * it should be integrated with the "magnificating glass" mode proposed above, so you could fine-tune any value using the hardware fader
  . and get a visible and tactile feedback even for the minute changes. I am not aware of any software providing such a feature at the moment;
  doing extended sound mastering sessions caused my quite some physical strain, because you need "almost not move" the mouse for hours ;-)
 -- ["Ichthyostega"] [[DateTime(2008-02-07T22:34:08Z)]]
== Support Joystick Port (Games Port, USB, re-assignable like keys and context sensitive) ==
 * Use of a Joystick port would enable the use of joysticks. Real physical slider decks could also be built with a few cheap components.
This would make it possible to advance the time line And adjust multiple faders all at once.

 * The joy stick switches could be used to change the purpose of the slider and/or set key points and labels.
 * the joystick pots and switches could be re-assigned just the way mappings for keyboards can be re assigned.
 . -- ["Tree"] [[DateTime(2008-05-07T16:26:00NZ)]]
== Mappings Management for Key Board, Joystick Port, Midi Devices, Parallel Port terminals ==
The settings could have a section to manage the mapping of keyboards, joystick controls, and midi signals.

 * This would help encourage the development of gadgets to make the fast Human Interaction with the editor interface easier.
 . -- ["Tree"] [[DateTime(2008-05-07T16:26:00NZ)]]
=== Key Board Mappings Manager ===
This is a handy utility for accessing keys and remapping keys on your keyboard.

Especially handy if you are going to customize (relabel keys) as an editing and joggling device.

http://keytouch.sourceforge.net/about.php

. -- ["Tree"] [[DateTime(2008-07-26T09:49:00NZ)]]

=== Typing and Editing as independent keymaps ===
For people like myself who use key layouts other than QWERTY, it is imperative that two different keymaps are used: the keymaps for editing that are designed for 2D locality on a QWERTY keyboard must read the scancodes from the raw interface, while typed text must use the keymap provided by X11 (or any other input manager). Any other situation leads to disaster during editing or naming/note-taking.
 -- ["NicholasSA"] [[DateTime(2009-01-04T03:10:23Z)]]

== Resources for making Midi Devices, Serial and Parallel Port Control devices using PIC MicroControllers ==
The Pic Microcontrollers from Microchip have a number of projects where they are used for midi devices. They can be interfaced to by switches, pots, etc. Linux has tools for compiling code to drive the range of PIC micros, and also has tools for driving the programmers (which you can build your self or from kits cheaply).

 * Microchip who make the PIC Microcontrollers http://www.microchip.com/
 * The AudioMulch web site has help for DIY PIC midi projects at http://www.audiomulch.com/midipic/
 * kits for midi interfacing http://tomscarff.tripod.com/
 * great programming tools in Linux for using PICs at the GNU PIC project http://www.gnupic.org/
 * tools for programming http://pp06.sourceforge.net/   ,   http://www.captain.at/electronics/pic-programmer/  ,   http://www.grennan.com/picprog/  ,   http://www.yty.net/pic/
 * There's plenty more on the web.
 * The lumiera project could start a sub-project to develop hardware interfaces and the hardware.
An idea might be to use the index wheels and sensors from inkjet printers to be used as jogglers/shuttles. *

 . -- ["Tree"] [[DateTime(2008-05-15T16:52:00NZ)]]
 .
== Resources for making USB Midi Devices and USB controllers using Atmel AVR MicroControllers ==
Atmel makes the AVR-USB, 8 bits cheap microcontrollers with USB. It's possible to make with AVR-USB, USB MIDI devices, USB joysticks, USB keyboards, etc. There is a firmware  [http://www.fourwalledcubicle.com/MyUSB.php USB library] with license LGPL V3 for AVR-USB, with working examples of USB MIDI, USB joysticks, USB keyboards, etc, and a list of projects using this library and the AVR-USB microcontrollers.

Development and hacking of AVR-USB are straight forward since Atmel supports AVR-GCC, the C compiler port for AVR which is available on most GNU/Linux distributions as Ubuntu. Also download of firmware to this devices are made using USB connection and [http://dfu-programmer.sourceforge.net/ dfu-programmer] - all tools are Open Source available on GNU/Linux.

== Record Turntables with Mice as sensors for Jogglers / Scrollers ==
Interesting information about how you can connect mouse parts to an old turntable, so you can scroll with "real feel" using this software. see;

 . http://terminatorx.org/turntable.html
[http://terminatorx.org/turntable.html ]

 . -- ["Tree"] [[DateTime(2008-07-18T22:18:00NZ)]]
== Open Sound Control (OSC) - control PCs, multimedia devices over networks ==
http://opensoundcontrol.org/introduction-osc

"Open Sound Control (OSC) is a protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology. Bringing the benefits of modern networking technology to the world of electronic musical instruments, OSC's advantages include interoperability, accuracy, flexibility, and enhanced organization and documentation. This simple yet powerful protocol provides everything needed for real-time control of sound and other media processing while remaining flexible and easy to implement.

Features:

 * * Open-ended, dynamic, URL-style symbolic naming scheme
 * * Symbolic and high-resolution numeric argument data
 * * Pattern matching language to specify multiple recipients of a single message
 * * High resolution time tags
 * * "Bundles" of messages whose effects must occur simultaneously
 * * Query system to dynamically find out the capabilities of an OSC server and get documentation
There are dozens of implementations of OSC, including real-time sound and media processing environments, web interactivity tools, software synthesizers, a large variety programming languages, and hardware devices for sensor measurement. OSC has achieved wide use in fields including computer-based new interfaces for musical expression, wide-area and local-area networked distributed music systems, inter-process communication, and even within a single application. OSC Application Areas ;

 * * Sensor/Gesture-Based Electronic Musical Instruments
 * * Mapping nonmusical data to sound
 * * Multiple-User Shared Musical Control
 * * Web interfaces
 * * Networked LAN Musical Performance
 * * WAN performance and Telepresence
 * * Virtual Reality
 * * Wrapping Other Protocols Inside OSC "
Open sound Controller is an improvement on Midi control systems, and works with PureData (a linux media system).

http://puredata.info/

http://opensoundcontrol.org/implementation/pure-data

http://puredata.info/Members/martinrp/OSCobjects/

Note: There are many more plugins and applications that work alongside Open Sound Control see below and elsewhere on the site - http://opensoundcontrol.org/

This could be used as a method of remote control/communication of Lumiera with performance devices to coordinate and capture the perfomance , synthesis of sound from video.

 . -- ["Tree"] [[DateTime(2008-09-29T14:10:00NZ)]]
----
= Toolkits =
== General ==
 * Use a scripting language (at least for prototyping)
 * Advanced users/entry level programers should be able to do simple configuration/customization tasks
 * Ideally one can reconfigure the GUI at runtime, at least without recompiling
 * Interfaces for plugins rendering into the GUI can then be defined by passing script code around instead C level abstractions of widgets
 -- ["ct"] [[DateTime(2008-02-07T23:50:23Z)]]
.. add more requirements here

== Concrete ==
 * Lua GTK is quite new but looks promising, a small reknown embeddable language, with a not too strange syntax/featureset adequate performance and a quite complete mapping of the gtk api
 . -- ["ct"] [[DateTime(2008-02-07T23:50:23Z)]]
== About Tooltips and Statusbar ==
Tooltips are really valuable items, they should not be wasted for simple things like brief help texts. Instead they might display the actual state of the underlying widget in a textual form (numeric+unit) with *maybe* some hints. Long time ago I proposed for Cinelerra to add a special mode to make tooltips editable, that is with a shortcut the actual tooltip becomes a small text input field where the user can enter exact values for some things, this value is committed with the return key and leaving this mode should be really easy (as simple as just moving the mouse, ESC key).

The Status bar can show more information but isn't directly in the users view, here we may play help infos like available options on the mouse buttons, important keyboard shortcuts etc. take a look at 'qcad' .. xfig has also static area where it shows available (mouse) options, just not a status bar but in the upper right of the screen.

This might be a bit different to some common other user interfaces (M$...) but I think this is much more valuable.

 . -- ["ct"] [[DateTime(2008-04-08T01:26:06Z)]]
----
= Measures / Metrics for "Usability" and "Intuitiveness" =
'''Usability'''(ease of use) - mouse clicks and motions, inputs decisions, etc required to achieve tasks. '''Macros '''are really handy for allowing the user to speed up repetitive tasks that the program designers have not anticipated and made easy to do from the outset. Macros can be shared on  a central web site. Plus developers can look and see what the macros are being used for, as this gives a very important indication of where vital tasks are.

 . -- ["Tree"][[DateTime(2008-05-07T16:44:00NZ)]]
'''Intuitiveness'''- how well the program matches the way a person would assume it might, and how well it hints to them about how they should be using it. For example, the "nudge" triangle has no explanation about what it does, and does not appear in the menu separately. . -- ["Tree"][[DateTime(2008-05-07T16:44:00NZ)]]

== Usability and Intuitiveness feature ==
'''''Smooth work flow''''' happens when the user is able to choose (or is even second guessed) what they want to do next, with minimum disturbance related to "how" it is going to be achieved. Every opportunity could be taken to have single clicks for common settings, and leave the complex stuff as "advanced" feature button access, in-depth settings, or the like. Where ever tasks may be highly variable over the total user population, but often repeated by some/many, the settings for those tasks should be made easy to repeat again, share with others, save, export, import, customise, and provide help/explanation on.

see http://www.notesatlarge.com/?p=33

 . --["Tree"][[DateTime(2008-05-07T18:49:00NZ)]] .
'''Usability Test System example'''

 . Test system at Ubuntu, includes recording of on-screen actions, mic, and possibly camera.
https://wiki.ubuntu.com/UsabilityTesting

 . -- ["Tree"][[DateTime(2008-09-29T19:47:00NZ)]]
== Usability Study - example of useability study of GIMP by University of Waterloo ==
ref; http://www.ingimp.org/node/9

"One of the fundamental needs when designing usable software is to know your user. If you don't know your user, then you don't know ''what'' you should be building -- you can only make educated guesses.

Commercial software companies employ numerous methods to understand their users and their needs. They run focus groups, conduct surveys, run user studies, look at marketing data, instrument their software to collect information about how the software is used... There are many methods to understand users' needs, but they all hinge on collecting ''data''."

"For volunteer-driven open source projects, real-world user data is much harder to come by -- there simply aren't easy ways to collect data about how users use the software in practice. To be sure, there are'' some ''avenues for collecting this data: Bug tracking software, mailing lists, and forums all provide outlets for users to describe usability problems and to indicate desired features. But only a tiny fraction of actual users take the time to contribute via these channels. As a result, information about how the''community''regularly uses the software is generally unknown for all open source projects."

"'''ingimp is an ''instrumented'' version of '''the '''GIMP '''designed to''' gather ''usage data''''', or data characterizing how the software is used on a day-to-day basis, by real-world users. ingimp is not a plug-in, but a complete, standalone application that looks and operates just like the regular version of GIMP, except that it logs how you use the software. Among other things, ingimp logs the commands you use, characteristics of your documents (number of layers, image width/height, etc.), and activity tags -- short descriptions that you can provide to describe how you will use the software. When the application quits, the usage data is automatically sent to this website."

"ingimp is part of human-computer interaction (HCI) research at the[http://hci.uwaterloo.ca/ University of Waterloo]. The project is led by[http://hci.uwaterloo.ca/faculty/mterry Professor Michael Terry]."

(HCI = "Human Computer Interaction")

inGimp has also set up the''' Stats Jam project '''which looks after the''' collection of the data at a website, analyses, and displa'''y.

 . http://www.statsjam.org/ https://sourceforge.net/projects/statsjam/     (for the code) ''' '''
'''Discussion'''

If a project like this can be done for a graphics editor like Gimp, then it could also be applied to a video editor. If it is needed for a program that is used for editing static pictures, then it may be even more useful for a program that edits moving pictures. This project could be applied to Lumiera for collecting and analysing the useability of the alpha, beta, and (for those who may want it) the stable release.

'''''Opportunity.'''''

It might be worth contacting Prof Michael Terry to see if his team would be interested in looking after the useability data collection aspect of the Lumiera code - i.e. they could receive the code, and insert the detection code. Even better, work towards having a plugin system, that makes it easier for programmers to insert detection points, which could also have been suggested/requested by users. This kind of system may operate in similar fashion to debugging systems, and there could be a benefit to adapting some debug systems.

Since Lumiera has a frontend that is independent of the backend/engine, then it is easier to adapt the GUI to make improvements, without having to re-write the whole program. A frontend system for programming/designing the GUI that is easy to adjust, would further make it easier to make  '''''adaptions to the GUI in response to lessons learned from the useability data'''''  that gets collected.

 . -- ["Tree"][[DateTime(2008-09-29T12:32:00NZ)]]
== User selectable Experience Level - Task Oriented Layout ==
The user could be asked to choose their experience level, and more complex options then get grayed out. The user could be asked the common tasks that the want to do, and other options could be grayed out. They can choose whether they want "grayed" out options to be available, or viewable, or not. The options which are advanced (or 2 levels greater than their current expertise level) could be "dark grayed" out and the user could have similar choices about their display) .

Could have a "lite" version and a "pro" version (easy and advanced versions).

 . --["Tree"][[DateTime(2008-05-09T20:50:00NZ)]] .
== Help System - available for user improvement ==
''Similar to tool tip and status bar suggestion above.''A''' "hover" hint / help''' facility would be a major bonus. Just make the function available, the box can start with an index number, and users can type in their own help comments (either in a''' help text entry management '''section, or directly into the pop-up hover box - in optional help edit mode).

These can be''' pooled at a central web site in to languages, and brevity/completeness''' (options to links to further help, links to examples, links to video tutorials). So the developers do not have to spend time writing help files - just make it possible for the users to. The developers might like to add a few comments to the verbose files at some later point, or clear up inaccuracies. translators can also do the work for other languages. Very quickly the supporting documentation's usefulness would add to the attractiveness of the program.

 . -- ["Tree"][[DateTime(2008-05-07T16:44:00NZ)]]
== Help System text available for download for translation ==
 . The text for the help system could be made available for download, so people can translate it. It could be referenced like legal documents with sections, clauses etc, so that translation is easy to do "bit by bit" and rapidly update the "small improvement". That would help people to do the translation without even having to form some group to coordinate the task.
Duplicate translations could be possible, so that if a user doesn't understand one explanation, then they can try another.

Users could rate the helpfulness and relevance of the help texts, to help tune up their effectiveness.

Some system like this would help get any kind of help up and running asap. Improvements can happen as time goes by.

 . --["Tree"][[DateTime(2008-05-26T08:37:00NZ)]] .


== Help and visual prompts use "Movie type Icons" (e.g. GIFs) for visual cue as to time behaviour of feature. ==
this was previously titled as
== Help and visual prompts use GIFs for visual cue as to time behaviour of feature. ==

Icons are handy when they portray some sort of cue for the task that they do. A number of tasks in video editing are time related. It would be handy to have some form of visual cue as to what the time related task does. Since Gifs can show motion, they would be very good for this task. PNGs could also do it it they were timed to cycle through their images. There may be other better methods to achieve the same effect.
Examples of uses would be to ;
 * show the difference between "track" and "stabilize" in motion tracker - a strip showing a pogo stick going along a footpath would be suitable to show the differences between track and stabilise (and could also be used to show the differences between the forms of vector calculation. 
 * Movie Icons could also be used to show editing functions that involve several important steps.
 * help with effects selection by Showing "what and effect does" rather than rely on some association between an effect's name or description, and a user's understanding or memory of what it actually translates into what gets done
 --["Tree"][[DateTime(2008-05-26T08:45:00NZ)]] .

== Further discussion of "Movie type Icons" ==
1) usefulness
"Movie type Icons" are a '''visual prompt''' to the user. They immediately give a visual clue/insight into what the item/resource/effect is/does. They are not dependent on the spoken language of the user, and nobody needs to understand technical words to '''see''' what it Is and/or what it '''does'''.
So as the beginner, starts to explore the program's capabilities, they are not required to learn a new glossary of terms And understand them, just to be able to appreciate what they can do with the program. Even if they get confused, they would be encouraged to continue learning because of their appreciation of its capababilities. The visual action of the Movie type Icons would increase the "self explanatory" experience of the program - a useability parameter.

2) not critical for now - but can be implemented in future.
This feature is not critical to the performance of the program, but could be implemented easily enough infuture if allowance is made now for it's eventual  incorporation.

3) Two factors of the Movie Icons make them useful - the subject content in the icon, and the action/effect that happens to it.

This would help a production team to more quickly locate items based on "user mode of thinking" - e.g. "Bob, do you remember the intro style we used on the project in africa ? - oh yeh there it is !" (a zebra with scrolling text over it, and logo flying in from top left).
This is a similarly efficient way to using photographs of customers as folder icons for the customer's related projects in business.
This method could be used for movie icons for effects, transitions, node edit sets, projects, clips, and more.
"More" might include a movie icon that is displayed in the tabs of parts of Lumiera, for example the tabs of track sequences - which take up less horizontal space than a meaningful name (though a name and description could be displayed when the tab is hovered over).

4) How Movie Icons could be made.

The laborious task of generating the movie icons need not be done at all by the Lumiera core programming team.
All that is needed is to allow the Movie Icons to be created (by say Lumiera - "save as" or "render as") from clips. In lumiera, this could even be done inconsequentially on the fly, just by selecting a strip where the effects/transition or whatever is happening, and render it to a movie icon, associate it it with the effect/transition being created/used and save it. Users can do this "as they continue to use" Lumiera, thus building up a stock of readily accessible self explanatory tools.
Users could share and upload their Movie Icons to the Lumiera project. A default set could be downloaded with the program, and alternative "themes" sets could be downloaded extra according to user's interest. In the first instance the first Movie Icon theme set can be made by using a standard video clip , with each video effect and transition method applied to it (this too can be done by the users).
The users can be encouraged to form groups to work on the themes. They do not need to have any programming skills, though graphic talents would be desirable (and very likely possed) by contributors.

5) Actions when Hover Over

a) Of course, the icons could still provide descriptive text when hovered over, and link to more indepth help which may include use in special applications, demos, and video tutorials.

b) another option which the user/designer may choose, is to have staic icons, and the movie icon gets shown instead of or along (as an insert) with the descriptive text box when hovering over the item.

c) other actions may include a vocal description played from a sound file.


6) Movie Icons and sounds

a) Spoken voice prompts could be played alongside the visual information, possibly containing a description.

b) In the case of Movie Icons for sound effects and transitions, the before and after effect sounds can be played. The sound that is played, can either be from file, previously created user effects, or generated live using the current tracks. The visual content of the Movie Icon could show what is being done to the sound '''wave''' .
--["Tree"][[DateTime(2009-01-31T11:41:00NZ)]] .

=== Offering Icons ===
I've created a set of icons with Cinelerra/Lumiera in mind that are available under the Creative Commons Attribution Share-Alike 3.0. You can *download/view them here*: [http://darkfirestudios.com/freestuff/videoIcons.svg] (SVG can be edited in Inkscape or other Scaleable Vector Graphics App) if you need to contact me you can find information on my website ([http://darkfirestudios.com/]). -Regis Frey

== Help using Video and Desktop recorders. ==
Desktop recorder software and Lumiera could be used for creating helpful video for ;

 * describing problems to help desk forums.
 * creation of tutorials
 * providing "more help"
Initial draft versions can be submitted, and other users can create more polished presentations, voice overs in different languages and voice types, later on. They could be available as additional downloads for help on different categories. The downloads could be initiated directly from Lumiera, rather than some outside operations that involve navigation to sites, through sites, and plenty of decisions. Direct from Lumiera by "link" to more help by "Video Assistant", then the user gets the latest list of video help files with descriptions, and can quickly select which ones they want. The list might also include approved external or mirror sites that can be accessed, to reduce load on the Lumiera server.

 . --["Tree"][[DateTime(2008-05-28T12:49:00NZ)]] .
== Help System - rolling tips and tutorials ==
Sometimes, when a beginner is using the program, they just sit back and look at the general picture. It's a behaviour that gets down naturally. It looks like a "break", but going through their minds are questions like ; "Am I doing this efficiently?", "What would make this easier, and is there already an easy way to do it in the program?", "How long do I think this will take, and what can I do to make it in time?", and much more. Sit back, look at the whole screen, maybe cruise around the menu, conceptualise the project and steps involved - it's a kind of task oriented learning - on the job (self) training.

The closest thing so far to something which takes the opportunity to make use of this "looking at the wider picture", is the tips that come up at the start - a kind of "while you are doing something - we thought you might find this helpful".

Because of the creative effort needed when composing video projects, there is quite a bit of vision based thinking. It is during these times that a help or instructional item could be presented to the user. (I am not talking pop-up advertising). Then user could set aside space for a window that scrolls help text, flashes tips, plays video tutorials or help. This help function could be optionally set to go on all the time, begin after x seconds of inactivity, or be manually triggered. It might even be a kind of screen saver - leave it running while having a coffee break. But what it does, is run a whole heap of options and new information past the user, in a low prompting mode, to a degree that they are prepared to have the minor distraction.

If it was context sensitive, then it would provide relevant information, similar to having a tutor or an expert leaning over your shoulder, explaining further possibilities and applications.

Video tips and Tutorials could be available via Youtube, which also doubles as promotion for the project. Users could choose to download groups of videos on selected topics.

 . -- ["Tree"][[DateTime(2008-06-11T17:04:00NZ)]]
== Suggest an improvement Feature - for users to help improvement ==
Just like the "Help" feature suggested elsewhere, inwhich the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a [:BrainStorimng:BrainStorming] page like this one (specifically for the panel they were in).

 . -- ["Tree"][[DateTime(2008-05-26T12:01:00NZ)]]
== Suggest an improvement Feature - using the Bugzilla model and code. ==
Bugzilla, the bug report and feedback system designed by the Mozilla crew might be handy.

 * Improve communication
 * Increase product quality
 * Improve customer satisfaction
 * Ensure accountability
 * Increase productivity
 * Bugzilla can adapt to multiple situations
http://www.bugzilla.org/

Bugzilla addons that integrate with project management software, source code project software, browsers, and IRC.

https://wiki.mozilla.org/Bugzilla:Addons

 . -- ["Tree"][[DateTime(2008-08-23T23:15:00NZ)]]
== Help feedback for quality management ==
Sometimes help files and tutorials are improvable. Keeping track of which help is to which amount useful for a majority of users will provide data about which help files are improvable. It will also provide data about which features most often users use help and might be candidate for usability consideration. like:

[]solved my problem []got me on the right way []needed to find help elsewhere []problem not solved

----
== "Render AS" ==
The '''process for creating a DVD '''where Video and Audio have to be rendered separately is laborious. A script could easily handle this, and make the use of the program so much easier, attractive, inviting, productive, time efficient, bla bla. All the user needs to do is set the parameters and file name (once) and then "do". Many commonly used formats for saving could be saved as presets that completely avoid all the questions (say in the "File" drop down menu, as a customisable "Render AS" choice). This could also be done for HDTV, iPod, Ringtones, VCD, Various formats that give the best performance for uploading to Youtube and all the other video sharing sites.

When a whole magazine article(s) can be written about the task of exporting a file to make a DVD, you know the process is a long one. mmm ... Any well paid journalists out there want to sponsor programmed task efficiency? - "NO?" - oh well.

 . -- ["Tree"][[DateTime(2008-05-07T16:44:00NZ)]]
== "Render AS GUI for ffmpeg, mencoder, ffserver, ffmpeg2theora (also oggfwd for streaming) ==
ref: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2008-April/013871.html

There is a need throughout Linux for GUI front-ends for the video encoder/transcoders. It would make sense, if the GUI were to have a common appearance for all of them. It would make sense, and be of great benefit, if the GUI's developed from the Lumiera project for these encoders/transcoders, were able to be used (with minor adaption) as stand-alone front ends for these programs. The standalone front ends would help to promote the Lumiera project to users of the encoders. Familiarity of use would be almost universal. Some general thoughts for the approach are;

 * Allow standard and commonly used user custom settings to be no more than two or three clicks to complete.
 * Have parameters that commonly need to be adjusted (for each respective codec), readily at hand (preferably with a short description of their impact).
 * The command's help file for the command options can be read from within the GUI
 * The command's help file for the command options may even be able to be automatically "interpreted" by the GUI to extract the command options, and list the settings available as multi-choice, or value required.
 * A method is used where users can share their settings with each other, and the Lumiera website. Comments can be attached to the settings, and read similar to the help file.
 * User can select their level of expertise, so they do not get confused by numerous obscure options. Novice, Experienced, Expert.
 * Where the explanation for the purpose of a setting is scant or absent, then a user editable extra help file would be handy for the experts to help build the ease of assistance that the GUI can give.
 * A tabbed interface would probably do well. 1st tab is for the quick common tasks, with an advanced settings button for tweaks, the last tab is for help, 2nd tab is for common uses but more complex features are available including build your script to save in the first tab, 3rd tab is obscure uses and options, other tabs can be used if there is a need for additional functions.
'''''           General Application Also''' ''

There are many command line functions that have manual and/or help files. These could all be given GUI interfaces, if there was a system for reading and interpreting their help file, to extract command options and available settings. All common settings could be submitted by users, for other users. A tool like that can do this would be handy for the transcoders, but where ever it gets developed would be a very useful "spin-off" for project for Linux. It would help with the "GUI-fication"/"Gui-ness" of the operating system.

'''''Useful code '''''There are some open source projects that have GUI front ends for some of these transcoding functions. If parts of these programs are used, then may be there can be some degree of "uniformity" in the appearance of the function. This would help those folks who use multimedia, as it would keep a familiar feel from program to program.

Some programs that may be of use for this are;

1) Vive - a GUI front end for FFmpeg http://vive.sourceforge.net/about.php

2) WinFF - a GUI front end for FFmpeg http://www.winff.org/

3) t@b Media Converter - a GUI front end for Mencoder http://www.thugsatbay.com/tab/?q=tab-video-converter-encoder [http://www.zs4.net/t-b-video-and-audio-converter3 http://www.zs4.net/t-b-video-and-audio-converter]

4) Kmenc15 - a GUI front end for Mencoder  http://kmenc15.sourceforge.net/

5) Konverter - a GUI front end for Mencoder  http://www.kraus.tk/projects/konverter/     also has a TV DVB called Klear

6)Theora Streamer - a GUI front end for streaming to IceCast and ShoutCast servers. http://gollum.artefacte.org/tss/

7) Theorur  - a GUI front end for streaming to IceCast and ShoutCast servers. http://sarava.org/theorur/

8) Boxstream - a GUI for firewire video capture, record and streaming ogg/theora over intranet, and uses IceCast servers for internet streaming. http://boxtream.unice.fr/

9) Xmffmpeg - a GUI front end for ffmpeg http://sourceforge.net/projects/xmffmpeg/

. -- ["Tree"][[DateTime(2008-05-31T14:56:00NZ)]]

== Output in a format ready to be used by DVD Authoring programs (including DVD menus) ==
The ease of home movie production and small business use, would be enhanced if the output was able to be immediately used for DVD Authoring, and may even include information to help automatically generate the menu and settings. This might include the ability to make decisions that effect the DVD menu/layout, from within Lumiera - like chapterisation, indicate positions in project where splits may be made if needed, locations where a break for adverts can be inserted (if making a program), and prompts to ask for the respective text inputs.

The facility to use the DVD Authoring program could be so integrated that, it may even appear to the user that they never left Lumiera to do it. The DVD authoring program might be skinned/styled like Lumiera, and appear within its windows (in agreement/liaison with the DVD Program project team). The sending of files and information to the DVD Authoring (and burning) programs could be set up as a batch, so the task can be automated (unattended, to be done when computer is not being used). New or Updated versions of the DVD production can generated immediately after an edit, with very little further oversight/involvement needed by the editor.

An example of a good Linux DVD program is QDVD Author, which has a good GUI, and features.

 . http://qdvdauthor.sourceforge.net/
 . --["Tree "][[DateTime(2008-06-05T19:54:00NZ)]] .
----
== Renda ==
=== "senda renda" ===
For projects that are working on separate networks, the projects can send a copy of their latest draft renders to each other, so each gets an update of what the total project would look like. In the case that it is known that the recipient already has the required raw data, then only the editing information is required, if the recipient is able to do the rendering themself.

 . --["Tree"][[DateTime(2008-05-09T16:29:00NZ)]] .
=== "requesta renda" ===
If a user is working on another network with just a small pc, they could be working on draft resolution video (speed and size savings). They can send their edits (ie the script used for "undo") to a user with grunty machinery, who can then do the rendering either on the draft resolution video strips, or on the full resolution video. This has several benefits for application to working groups - use unused resources on a remote render farm, able to incorporate remote workers that don't have high powered PCs.

Transfer by email, shared web folder, shared folder on network, download from web site automatic or email initiated.

 . --["Tree"][[DateTime(2008-05-09T16:29:00NZ)]] .
----

== Crash detection with Auto Restart ==
When the program is called to start, another "start" program can be started first. the "start" program knows that Lumiera has been requested to start. It could be used to monitor start up processes and glitches, but mostly would just sit in the background to check on whether Lumiera is still running. One way for it to know if Lumiera is still running is if Lumiera writes the value of the clocks time to a register that the "start" program reads at frequent intervals (say the noticeable reaction speed of a typical person). If the "start" program detects that the time has not been updated within a suitable delay after the check interval, then it looks at system processes to see if Lumiera has crashed and will then automatically re-start Lumiera. AAAAND also re-load the backup. This saves all the manual work by the user. Makes a far more "fail safe" return to work for the uninitiated (no learning curve of sad losses). Saves time -keeps goodwill of users high.

It could even generate reports automatically for debugging and diagnosis, report system loads, detect impending hangs (because of increasing, though acceptable delays).

 . --  ["Tree"][[DateTime(2008-05-07T17:15:00NZ)]]
== User Precautions get built out of user interface and into program. ==
When attaching such and such effect to a track, disable "play" before attaching it, then re-enable play aft attaching it. (we don't tell you this before hand, and we never will, unless you ask the question and search the net, then you might find out in the "secrets manual", And you'll have to remember this (always)!! If there are circumstances that apply to an effect (or for that matter any other part of the program), then the feature could have a flag in it that warns the system to take note of it, and it then reports what its requirement or tweak feature is, so the system can automatically handle it the best way. (A sort of OO process handler). This not only saves potential lengthy wastes of time, but saves concentration on sideline issues, speeds up work, adds to reliability and good time user experience.

 . --["Tree"][[DateTime(2008-05-07T21:34:00NZ)]] .
== Gather stats from the "UnDo" process ==
Get statistics from the functions that get most commonly "undone". This would help indicate whether there is a problem with users making mistakes, or a better "try and see" method can be included in the function. Since heavily used functions will also likely have a higher rate of "undo", then stats on the use of functions can also be gathered so the "relative undo rate %" can be calculated. This info can all be automatically gathered, so is no effort for the user. The user could be asked to activate an automatic send a central web site, so no privacy/consent issues. User could be allowed to attach a comment. All data automatically handled at web site, and alerts automatically generated for developers if "undo" rates exceed a predefined "acceptance level".

 . -- ["Tree"][[DateTime(2008-05-14T09:55:00NZ)]]
== Time estimates for lengthy Tasks made known, before committing to the action. ==
Handy to have time estimates for lengthy task indicated even before committing to the task. Also an estimate for the % increase or reduction in time of adjusting parameters. So you can make a good tradeoff between the result and and the time taken to get it. When a task is carried out, measurements are made to improve the accuracy of future guesses.

These may initially be inaccurate ball park guesses based on "rule of thumb", but will probably be with-in an order of 10.

Performance data from previous use (and other users) can be collected over time, to improve the accuracy of the guesses. This might even allow an estimate of the accuracy, to be shown - say "Time to complete is expected to be 7 minutes +/- 30 seconds" or "This will be completed between 6.5 to 7.5 minutes from now".

The performance data could be made available (user permission needed) to be sent back to lumiera, to help improve the initial guesses built into the software, and update  the guess data files. Users could download the latest guess data files, which might be catagorized by the type of machinery used.

Considering integration into the system, all time consuming processes could have a parameter for the duration estimate. In the early stages of the project, there will be few processes that can even estimate the duration and so they would just report "duration unknown" or maybe "duration uncertain but allow X seconds per frame"(or similar type of message). This allows "null information" to be presented in the GUI. Estimate algorithms could include consideration of processor type, clock speed, bus speed, ram, swap file size, and what else is being done by the computer at the time, or run actual preliminary tests to calibrate processes. But in any cases, after the first few processes have been done and the duration times recorded, then the future estimates can be made on the basis of past "job volume" sizes divided by respectivce "job duration"s multiplied by current "job volume". "Job volume" depends on what the process is, but may be measured in file size, number of frames/time, number of complicating influences (e.g. effects to be applied), etc. In the end the data used to make the estimates can come from the internals in the depths of the system. But in the first stages, it is helpful even if the user can just supply their own (or others) ball park algorithms. for example; estimated time for render to DVD format = time length of movie x average number of tracks being mixed   plus or minus 15% so ... Estimated process duration = 1hour 30 mins accuracy = +/- 14 minutes choices -  1) do it now 2) do it sometime later (manually) 3) create a batch process 4) cancel

In the case of "do it later", it can get added to "session assets" list of "yet to do" processes. Then it just neds to be clicked on, and choice confirmed, to be activated. As a process it could even be saved for redoing (re-rendering) again later.

 . --["Tree"][[DateTime(2008-05-07T21:34:00NZ)]] .
== Operating System and Hardware Tweaks ==
If the operating system and/or hardware can be tweaked for better performance, then the program is the best place to manage those tweaks, especially if they can be made when the program is started and reverted when it closes. The program could generate a splash screen for booting so the user never forgets that system settings have been changed (that may effect other programs), and a splash window for when Lumiera starts could have similar information for the settings it changes just while it is running. Where tests can be done to estimate the optimum setting, Lumiera could do that automatically and suggest the setting.

Hardware tweaks may include hard disk write caching, read ahead, DMA, recommended file system (partitioning and formatting), shmmax settings for memory, swap file size depending on the project size and memory size - or not use swap at all - or set up swap on a separate hard drive (to save on head seek time) or fast plugged in memory HD, monitor tweaks (not just speed but appearance - and optimum refresh rate, considering other system data flows)

 . --["Tree"][[DateTime(2008-05-07T21:33:00NZ)]] .
== Default settings after install set to most reliable and least requirements ==
The program may be tweaked to get performance on PC with great graphics systems, plenty of Ram and good hard drive speed. For people with lower spec'd gear, there may be some tuning needed, just to get going. There is the likelihood that people with low spec'd gear are not so able or inclined to read up on their hardware, and "search" for help on their video editor, to find out the solution to a problem (which they may not even have much idea of what the problem is). Consequently, they are likely to give up and not use the program.

Everybody enjoys a program that can be easily installed, and is ready to run. Few are upset by a program that is easy to install, setup, and is ready to run. But quite a few have nothing but disappointment with a program that is relatively easy to install, no idea how to set up, won't run or crashes, and not much clue about where to get help which is much further away than a click.

So it would do the program a great service to be able to run on just about any gear, straight away. This means using setup defaults which are general and as universal as possible, unless the program is given some sort of intelligent hardware detection function (not a big priority at this stage as it would require more programming work and folks are busy on more important tasks).

The tweaking could be left for the experts to get speed, rather than the noobies.

The tweak options could have say three general default settings, that progressively ramp up the performance demands, so the user can try the settings to very quickly get an idea of their gears trade-off between speed and reliability. each section of settings that has options, could be laid out so that increasingly demanding options are lower down the choices or colour coded for System requirement.

Colour coding may be red for heavy loadings and risk, yellow for low demands, and a colour blend between. The saturation of the colour may also indicate the preference to reach at least that level with your gear, so you know how to "trade off" between parameters that your are going to tweak up. This makes it a little more intuitive for how to drive your gear up to "red line" level.

A similar colour coding for speed could be used ; blue for low speed, green for high speed.

This colour coding for the two parameters (reliability and speed) means that when new driver/setup options are available that provide a speed increase, (yet are unreliable or unknown reliability at the time), the user has a very easy visual prompt to help them make decisions, and adapt their trial and error path to optimisation.

Feature to save different hardware settings, with notes in the hardware specs, and share them. Upload to Lumiera web site, so that better first guesses for new users are available. And if an intelligent system is used for hardware detection in future, then the information for best choices will already be available.

 . -- ["Tree"] [[DateTime(2008-05-28T09:41:00NZ)]]
== Rapid take-up by Cinelerra users and potential users ==
In the first instance (and when ever possible), make preparations for future adjustments, so that the presently possible is made available. e.g. Cinelerra is currently available. Lumiera is not. Lumiera could use the very same code, but chop it up into similar sections as intended for Lumiera to in. It might make for some additional complications during development (such as handling of old and new variables during a transition stage). But it means that people can start moving across to Lumiera NOW, and can be part of the development cycle. This means the developers can start getting feedback much earlier on, and get assistance along the path. When people can begin to see "where" something is heading, and "how" it is getting there, if it looks like fun and productive, then they'll jump on board. So it's not just about a "clean" development path to excellence, but also honing it to users, and users helping also, and others developers getting keen and joining in too.

When the support arrives, it would be nice to be sharing code clips back with the Cinelerras. After all, they may like it too.

 . --["Tree"][[DateTime(2008-05-07T20:11:00NZ)]] .
== Rapid take-up by Cinelerra users and potential users - easy transition from old to new ==
Just like word processors (e.g open office), the user's transition from the previous product to the new product, is aided by "familiarity". This means being able to do what they want, in a way they are already able to use, "while" being invited/encouraged/exposed to the new way available.

So it is handy to have the new program able to operate in a mode similar to the predecessor, yet able to be easily changed in any area, to the new program's method.

The old/new management of each stage would be similar to the management of expertise levels. In fact it could be treated as an expertise level prior to novice in the new level ie "Expert Cinelerra". It makes for more bulk in the program. But also is a good fall-back in the case of buggy code, or difficulty for user of the GUI. After a while it could get separated (from the main download), and kept as a plugin.

The user could choose to have the old and new option available at each menu choice (and the program could "learn" which option they would prefer (after say "x" decisions). Or the user could choose to predefine their choices for old/new at each menu choice on a table, which they can come back and review as they alter their experience levels.

This information may be made available for sending back to the Lumiera project to help get an idea of how quickly people choose to move from old to new options.

This method could even be used to handle more than one type of new option. Very good for allowing people to choose (for example) the kind of "sliders" they want displayed in each case (knob, numerical, horizontal, vertical), and other forms of display panels/skins.

Another way to have old and new available, is to let the user select the default for the choices in the menu, but if they want to try out the other (or next level up) option, then they select the choice of task with a right mouse click rather than a left mouse click.

 . --["Tree"][[DateTime(2008-05-26T10:57:00NZ)]] .
== Provide Binaries for all common platforms and Systems ==
This is a major way to increase the take up speed of the program. Many people have i386 versions. But this is multimedia so the few that get into 64bit AMD or Intel are likely to be the ones also interested in Video. But everybody can be a user if catered for. Just need to set up the respective options for automatic compilation. When people see that they can use a program on entry level equipment, gain expertise, then invest in gear with OOOMPH when they can drive it fast, then they'll be keen to start using it, and will continue to use it. Whether the Binary compilations are done in house or by others, it helps to have the process coordinated and streamlined so they are all kept up to date.

See information on free "build server" services for compiling at Suse and Ubuntu below.

 . --["Tree"][[DateTime(2008-05-07T21:33:00NZ)]] .
----
== "Undo" Edit manager - becomes Macro Manager, and Wizard Generator ==
This is basically '''''recording a script of all the video edits made''''''''''''''''''''''''''''' as is currently done by '''''the "undo" process'''''. This script could be used to extract repeated processes. These processes could then be made repeatable by a single click (with facility to customise some of the adjustments).

These processes could also be used for drive through demos, or tutorials, where the user can make their own adjustments, to the tutorial.

They could also use the same scripts to apply to their own tracks, acting like a wizard.

Users can share these macro/processes/tutorials/demos at the central web site.

 . --["Tree "][[DateTime(2008-05-09T15:07:00NZ)]] .
== Making Applets from Macros ==
Where any macro may need to accept variable parameters, there could be a simple window panel maker, that generates the fields that need to be input. This then creates sub-functions, or major functions that can be set up, and then left to do their job. It might be that Lumiera could automatically generate the input panels. But in the first instance, users could share their macros, and note what the variables are, and other users can volunteer to convert the macros to input panels.

. --["Tree"][[DateTime(2008-09-08T23:46:00NZ)]] .

----
== Import and Export SMIL files ==
Many current cinelerra users probably use kino for their capturing of DV. it uses less resources, so less system demand during capture. Good display monitor while capturing. Open Movie Editor is a good multitrack editor that can share Kino's SMIL files. A good progression in complexity of editing is start with kino, move to OME, then cinelerra (lumiera). A really convenient way to assist stepping up from Kino is to handle the SMIL files.

[http://www.kinodv.org/ http://www.openmovieeditor.org]

http://www.kinodv.org/

'''''Automatic scene detection'''''is a great feature in Kino. The simpler editors make it easy for less skilled people to look after the selection of preliminary clips, while lumiera is used by the folks who put it all together, and finish it off.See other comment on EDL (edit decision lists).

 . --["Tree "][[DateTime(2008-05-09T15:10:00NZ)]] .
== Import and Export RFX files - a current example of editable effects and transitions. ==
The LiVES video editing and VJ system has a feature for creating and editing effects, transitions, and utilities, called "RFX".

'''RFX''' stands for '''rendered/realtime effects'''. It is the open standard being developed by the author (Salsaman - G. Finch) for passing parameter window requests between applications, in this case, LiVES GUI and its plugins. The '''schema separates parameter type from layout'''. It can also contain sections for '''processing''' of those parameters '''in multiple languages'''. Finally, an RFX script is compiled into an application specific plugin, depending on the application and target language.

[http://lives.sourceforge.net/index.php?do=addons http://lives.sourceforge.net/index.php?do=features]

http://lives.sourceforge.net/index.php?do=addons

 .
Allows quick and easy prototyping of new tools, utilities, effects, transitions, generators and more, using the included RFX builder window (additional feature).

 . http://www.xs4all.nl/~salsaman/lives/img/pbuild.jpg
Excellent tutorial on lives. http://www.reimeika.ca/lives/lives_guide.html

The code for this project (FOSS) may be available for use, to allow Lumiera to share the same functionality, and share the resources created through the users of both programs.

Note: LiVES can grab and record video input from Firewire.

 . --["Tree "][[DateTime(2008-08-23T22:50:00NZ)]] .
== Import and Export Effects with other Linux Video Editors - may be? ==
KdenLive video multitrack editor (with firewire capture) has a feature that allows users to share luma transitions with other kdenlive users. see how at

http://en.wikibooks.org/wiki/Kdenlive/FAQ#How_can_I_create_luma_transitions.2Fwipes.3F

http://kdenlive.org

 . --["Tree"][[DateTime(2008-08-25T19:05:00NZ)]] .
== Compatible and Interoperational with  "MLT"  structured multimedia programs. ==
MLT is an open source multimedia framework, designed and developed for television broadcasting. It provides a toolkit for broadcasters, video editors, media players, transcoders, web streamers and many more types of applications. The functionality of the system is provided via an assortment of ready to use tools, xml authoring components, and an extendible plug-in based API.

MLT is used in KdenLive video editor, and MLT/Miracle video playout server for television broadcasting.

http://www.mltframework.org/twiki/bin/view/MLT/

This is worked on by Dan Dennedy, who is of Kino and some other video projects.

http://www.dennedy.org/twiki/bin/view/MLT/Features http://www.dennedy.org/mlt/twiki/bin/view/MLT/Westley

 . --["Tree "][[DateTime(2008-08-25T22:10:00NZ)]] .
== EDL to AAF Converter Project ==
"EDL to AAF allows CMX3600 EDLs to be converted to AAF files. It has been made open source to encorage all AAF developers to use the same operational pattern (semantics) and thus avoid a Tower of Babel!"

 . http://sourceforge.net/projects/edl2aaf/
The team at the EDL to AAF Converter project may be willing to collaborate with the Lumiera to make their code available for making these various systems compatible. This would lighten the workload on Lumiera, in order to get this functionality, or conversely leave room to expand the functionality of the results.

 . --["Tree "][[DateTime(2008-09-01T21:51:00NZ)]] .
== VideoGrok - to handle SMIL, RSS and RDF and metadata ==
"VideoGrok is a set of applications for relating metadata to segments of video, and then locating and analysing these, with interfaces to technologies including SMIL, RSS and RDF. Currently based on Quicktime for Java. This restriction will be removed."

 . http://sourceforge.net/projects/videogrok/
The team at the VideoGrok project may be willing to collaborate with the Lumiera to make their code available for making these various systems compatible. This would lighten the workload on Lumiera, in order to get this functionality, or conversely leave room to expand the functionality of the results.

 . --["Tree "][[DateTime(2008-09-01T21:42:00NZ)]] .
== (Auto) Repair EDL, SMIL, XML, etc Edit Lists after resources (e.g. clip resources) get moved, and "transportable" edit lists associated with clips. ==
The edit lists include references to the resources that get used to do the edits. This includes such information as the location and names of the clips that are used.

If the clips get moved, or moved "relative to" the clip, then the edit list for the project is broken.

This can be terrifying for a user, but is very easy to fix, but only if you know where to look.

The fix can be done (and should be automated), by extracting the file names from the edit list, and searching for them on the computer. The last known folder is also kept in the edit list and can be used as a starting point to the search, or to help prioritize the most likely result.

This same repair/system maintenance feature, can be used to provide the flexibility for the user to re-arrange the folder structure for their filing system, because all the edit lists can be automatically adjusted.

Copies of the edit lists can also be made and sent to other folks, with the resource locations as per the locations on those folks's pcs (their folder structure would have to be preknown). Or the edit lists can be structured in such a way, so that resource locations are given a standard name (e.g track01 ...) and can be replaced with the actual locations as per the machine they are being used on. (This same method would probably be the way to save edits that will be re-used on other tracks, anyway).

It's just a matter of simple text "find and replace", to update the edit list.

The same function can be used to allow clips to be moved, and the associated edit list(s) be updated with the information about the new locations. This could also be used for re-associating edit lists with segments of clips that have been chopped/extracted from an original clip using its original edit list. This makes file management possible "after" a project has begun, or has even been completed.

It would be possible to search the edit list for a complete list of resources, and have them displayed as a report, which could also indicate whether they still exist at the stated location, or can be found elsewhere.

. --["Tree "][[DateTime(2008-09-05T10:37:00NZ)]] .

== Import Edit Decision Lists from other programs and older devices. ==
ref: http://www.edlmax.com/maxguide.html For people and organizations with archives of footage and projects that were made on their old equipment/software, it would be a great help to be able to import those projects and archives into a modern program. The "translator" could either be a separate utility, plugin, or program component. It is the ability to easily transport all (bulk) previous projects, archives, and raw material that makes it attractive to upgrade a studio to a new system. A translator designed with this function in mind, could be instrumental in encouraging studios to give Lumiera a try - even just based on its ability to modernize the original (cataloged) material.

 . --["Tree"][[DateTime(2008-08-22T20:17:00NZ)]].
== Cinelerra XML project for collaborative video editing - Drupal web CMS and Final Cut Pro XML. ==
see http://osvideo.constantvzw.org/

"During the last week a small group of people have been working with[http://deptford.tv/ Deptford.tv ]at[http://dek.spc.org/ Deckspace], Greenwhich on setting up a system for collaborative video. Building on the proposals by the[http://osvideo.constantvzw.org/?p=17 Echo chamber project]to connect Final Cut Pro’s output XML to Drupal, thought has been spent on creating a system involving the XML output of Cinelerra, based on this first draft -see below- made by Adnan. The aim is to produce at the end of next week a flowchart that maps the process, and from which possible optimisations of the system can be derived before the next Deptford.tv workshop will take place in october. The[http://watch.deptford.tv/ database of Deptford.tv]is excellent case study material for trying to set up such a system." ...

 . .. "Lisa Haskel installed a SVN versioning system, which can be used by editors to exchange cinelerra output xml files. Meaning off course that all editors will have to work with Cinelerra, which I find excellent and exciting news. One way of permitting editors to opt working with Final Cut Pro could be to write a script that translates between the two software’s differently formatted project XML’s" ...
See a related project that could take cinelerra XML and translated it to Final Cut Pro XML, and use on a plugin for the Drupal CMS web site design system.

 . http://osvideo.constantvzw.org/?p=17
. --["Tree"][[DateTime(2008-09-26T12:41:00NZ)]].

----
== GNU Video Effects project ==
The GNU Video Effects project are blender3D animators and vídeo editing users, that want to make templates for video effects/compositing.  SPANISH: Somos animadores de blender3D y editores de vídeo que queremos crear plantillas de efectos de vídeo/compositing.

http://sourceforge.net/projects/gvfx/

This project is just in the planning stage. This project could prove to be the source of talent and inspiration for effects creation editors (type) plugins, as well as just the effects.

 . --["Tree "][[DateTime(2008-09-02T12:30:00NZ)]] .
== GNU Video Effects and closer integration with 3D modellers ==
3D modellers could be used to create effects and effects templates. One team is currently using Blender. There is also another 3D modeller/animator called "Art of Illusion" which is a free, open source 3D modelling and rendering studio. It is written entirely in Java, and should be usable on any Java Virtual Machine which is compatible with J2SE 1.4 or later.

http://www.artofillusion.org/index

http://sourceforge.net/projects/aoi

http://en.wikipedia.org/wiki/Art_of_Illusion

As well as creating animations, 3D modelers can be used to map images as textures onto 3D shapes, and move objects through paths, morphing, and creating advanced transition motions.

 . --["Tree "][[DateTime(2008-12-11T18:12:00NZ)]] .

== Zwei Stein effects editor example ==
Zwei Stein from ThugsAtBay have a linux video editor that handles effects. 
The effects editor shows a before and after view of the video and effect, and includes drawing and masking tools. It also includes a view of the "destination" (an equivalent of Cinelerra's "Projector" view). The layout locations of the features is sensible.
The visual appearance of the GUI is phased by the use of high contrast fonts, and font style spacing, as well as lacking use of color (e.g. color sliders that are "named" (ie green, red) when they could simply be colored to "show" which color they are, and maybe even toned so the slider would indicate where the slider needs to be set to obtain a desired tone.


http://www.thugsatbay.com/tab/?q=zweistein

http://www.thugsatbay.com/shared/nscreen.jpg

 . --["Tree "][[DateTime(2009-01-31T13:10:00NZ)]] .


== MatteLab - blue screening matte utility for video and stills in Java - possible plugin/alternative. ==
Mattelab could be adapted as plugin. It is GNU open source and written in Java. MatteLab Features ;

 * blue-screen matting utility.
 * capable of matting by hue, saturation, and value.
 * added feature of alpha blurring to make the edges blend in with the rest of a scene better.
 * The algorithm also de-saturates anything that is filtered out, so any halos or overspill from the alpha-blur is less visible.
 * de-saturation by transparency is possible.
 * dynamic filtering, where the transparency depends on how different each pixel is to their target matte values.
 * a correction factor to allow full transparency, and a correction slope.
GNU Video Effects projecthttp://www.nccn.net/~w_rosky/evan/evan/programs/mattelab/tutorial.html

It has a nice GUI.

Note that it selects a rectangular color space for the matte.

'''''Improvements for Setting matte colors'''''

It might be possible to use a free draw line to choose a range of colurs where the saturation or hue is not constant (like used in drawing programs to select complex areas). It might even be possible to define more than one set of colors in a matte. Mattes could be created and combine or subtracted to make new mattes. A eyedropper could be used to select some typical colors, or the color range for a matte. An area of the image could be selected and the colors for the matte extracted from that area (and then the matte color set could be be fine-tuned).

'''''Improvement for De-Speckle and enclosed Object removal'''''

Where a pixel is not removed by the matte, but is totally enclosed by the matte, it could be removed - this removes speckles. This can also apply to pixels that are in connection with X-or less number of other pixels which are enclosed by the matte colors. And another criteria may include some form of shape definition (e.g. if within certain distance from a central point, or within a defined shape {circle, rectangle, irregular drawn} limit from a central point). This would help to automatically remove objects. There could be an option to either automatically remove, or prompt, and remember the decision to allow or disallow removal for each object.

http://www.nccn.net/~w_rosky/evan/evan/programs/mattelab/images/open.jpg

It might be possible to use a''''' Java to C++ Converter '''''to make it C++. Maybe using demo converter at - http://tangiblesoftwaresolutions.com/Product_Details/Instant_CPlusPlus_Java_Edition_Details.htm

Or

a first pass conversion using  http://www.fasterlight.com/hugg/projects/ssbt.html  which would probably need correction afterwards.

Or

For Java JDK1.1 to C http://www.cs.arizona.edu/projects/sumatra/toba/

 . --["Tree "][[DateTime(2008-09-03T13:05:00NZ)]] .
== Exymen - video editor and web streamer project working with Java and OSGi plugins ==
Exymen is a GNU universal cross platform multimedia editor, aiming to have one application capable of editing '''''all kinds of media''''''''''''''''''''''''''''' content, including''''' sound, video, slide presentations '''''''''''''''''''''''''''''and''''' white board content'''''''''''''''''''''''''''''.   The vision will eventuate by many developers '''''using Exymen as a rapid  prototyping tool''''' for new media formats and codecs on the one hand, and by  many users using Exymen as a free tool for editing media content on the other hand.

Exymen is based on a diploma thesis of computer science (German equivalent   of a Master of Science thesis). The goal was to create a'''''Java based editing   tool'''''for web-streaming lectures produced with the E-Chalk System. The original   task was to design a uniform GUI for the editor and to define data structures   capable of handling all different content types in E-Chalk lectures, which   include sound, video, board content and slide show events. The author then   generalized the problem by providing abstract data structures   that allow handling all kind of time based media.

Exymen has an  open  API, enabling developers to write plugins that fill the abstract data  structures  with different types of formatted content. Exymen has a powerful  and dynamic plugin managing mechanism based on the''''' OSGi standard''''' (the Dynamic Module System for Java).

http://www.exymen.org/

http://www.osgi.org/Main/HomePage

 . --["Tree "][[DateTime(2008-09-02T01:55:00NZ)]] .
== Other Video editor projects that lumiera could team up with to share code and set conventions for functions (e.g. plugins). ==
There are a number of Linux Video editor and Video Production projects that are just in the starting stages. These could be contacted and asked if they want to share code, collaborate, share plug-ins, or at least form some form of compatibility to share things like plug-ins, effects, EDLs etc.

e.g.

Positron  NLE video editor. Geared to be a replacement for applications like Final Cut Pro, Avid, and Smoke. http://positron.sourceforge.net/

StudioDE http://studiode.free.fr/ http://sourceforge.net/projects/studiode/

MOB [http://sourceforge.net/projects/mob/ http://mob.bek.no/]

Rasterrain video and node editor http://sourceforge.net/projects/rasterrain/#item3rd-1

Kut. Video editing for KDE using Gstreamer http://axis.sourceforge.net/

Pihlaja is GOING TO BE a scene based video and audio editor, written in the D programming language, using gtkD, gtreamerD, Gnonlin and cairo. It is very much alpha stage. http://pihlaja.sourceforge.net/

Open Media Studio - OMS is used for sequencing events on a timeline, allowing control of software and hardware for music, video, and demoscene productions. It is fairly similar to music trackers. http://sourceforge.net/projects/oms/

JANE - Just Another Non-linear Editor - uses plugins http://jane.sourceforge.net/

GNLinear http://sourceforge.net/projects/glnlinear/

Lights Camera Mono! http://sourceforge.net/projects/lightscameramon/ AviSynth

NLVE -                          Non-Linear-Video-Editor http://sourceforge.net/projects/nlve/

Sparks Editor - multi-track audio/video mixer. Key features include simple and intuitive user interface, large audio and video  '''''special effects library, plugin and scripting'''''  support. http://sourceforge.net/projects/sparkseditor/

HastalAVIsta - a graphical video editor for Linux. (stalled project) http://hlavista.sourceforge.net/

GNU Video - nonlinear video editor with the look and feel of Ad*be Premiere Pr* http://sourceforge.net/projects/gvid/

Maestro Project - scene graph based multimedia editor http://sourceforge.net/projects/maestro/

The Movie Kit - A kit of tools gathered in one big software designed to  '''''make special effects'''''  and editing on movies. It is written in C++ using wxWidgets for the interface and DirectX for 3D, Video, Audio, ... . For windows, but written in C++ so some code may be useful.  http://sourceforge.net/projects/moviekit/

SNICE - An image compositing program. It is made especially to help  '''''create special effects'''''  for video and cinema. It work on Win32 and Linux OS. It is writen in C++ using OpenGL.  http://sourceforge.net/projects/snice/#item3rd-1

Video Synthesis - A collection of utilities for depth-recovery for sampling of objects and synthesis of multimedia for two and three dimensional presentation. http://sourceforge.net/projects/synvd/ CinePlug

CinePlug - a collection of'''''audio and video plugins for cinelerra'''''written in C++  http://sourceforge.net/projects/cineplug/

iMovie Plugins project - aims to foster independent plugin development, provide a community to support aspiring iMovie developers, and deliver high-quality, free plugins for a high-quality, free program.  http://sourceforge.net/projects/imovieplugins/

AviSynth

AviSynth related -

vdio - will be a cross-platform, non-linear video editing system built on top of the currently under development AviSynth v3. http://sourceforge.net/projects/vdio/

AviSynth Pre-Processor - AVSPP - Avisynth Preprocessor is a tool for preprocessing Avisynth scripts, allowing script writers to integrate PHP with Avisynth scripts. It allows access to remote images and videos, loops, and other functionality that is easily accomplished in PHP. http://sourceforge.net/projects/avisynthpreproc/

'''Complete Video production Suites - workflow - early stages'''

mdesigner - a tool to create and design complete movies. It is written in C++ (no downloads yet) . http://sourceforge.net/projects/mdesigner/

Post Production One - will provide a common development architecture for several cross-platform open-source applications for the Feature Film and Video Production Industries. The scope will include a production planning tool, a compositing tool, etc. http://sourceforge.net/projects/postprodone/

Zeroglab_TdotM is a general purpose'''''  automatic film writing''''''  (workflow)'''''program. The project is made with 'Pure Data' (PD), a real-time graphical programming environment for live interactive computer music.http://sourceforge.net/projects/tdotm/

 . [[DateTime(2008-09-02T12:50:00NZ)]] .

== Palantir multichannel capture and mega channel streamer - can work on low perfomance PCs ==

Server and Clent components.
Server can be even just a 486.
Client can be an ordinary player, or some web browser plugins.
Bandwidth required is full duplex phoneline.
Another connection channel allows for remote control and feedback to/from server (e.g. for cam pan/tilt, lighting control, straingages, etc)
Stream over LAN, VPN, or Internet.
GPL license.

http://www.fastpath.it/products/palantir/index.php

 . [[DateTime(2009-01-15T23:01:00NZ)]] .
----

== Easily Updateable Features ==
The program can manage some of the online resources that users develop. Access the central site, get directed to mirror of choice, get latest list of optional features. features such as effects, program skins, audio, video, titles, preset keypoints, tutorial videos, help files, language files, plugins, etc. This makes the results of any artistic contributors much more rapidly dispersed to users. Allows much more tayloring of program to users liking/needs.

 . --["Tree"][[DateTime(2008-05-07T20:10:00NZ)]] .
== Tool Bar or Tab Bar with icons of windows to manage the display ==
This acts like a task based toolbar, but the icons are more meaningful. This toolbar acts as a window displayer, to bring to the front the window icon most recently clicked. This is a convenient way to find the window you want when the desktop is highly populated and windows have to overlap. It hopefully is so easy the each window could be maximised anyway. The toolbar effectively acts as a "tab bar" to bring up the different boxes. It saves looking for the main window (which can now get lost behind full screen composers, and luxuriant resource folders, and overlay /resource tables). It saves looking for whether the "x or _" is visible, possibly by having to click elsewhere on the window to highlight it. It saves clicking on the buttons in the task bar that either are not well labeled, all carry similar icons, or are labeled but the text differences don't appear until after the text has disappeared.

The toolbar could (by default) run down the left side of the screen, and show the buttons in the order of process that the user is likely to need them in, but could be customised by the user anyway (and shared with other users). Or it may run across the top as tab bar.

 . -- ["Tree"][[DateTime(2008-05-07T20:54:00NZ)]]
== Menu Bar disconnectable from track view ==
The menu bar could be made disconnected from the track view. This would allow the track view to be covered by a window, but the menu still kept on top. The menu bar could by default start at the top left and run across the screen. It could remain on top view. It could include easy single click tabs to jump from one window view to another.

The menu items that are specific to track view could be separated out and left as dedicated menu attached to the top of the track view.

 . -- ["Tree"][[DateTime(2008-05-07T21:06:00NZ)]]
== Tabs Bars or Zones that you can "Drag Through" to enable "drag"-ing from window to window ==
A system that uses buttons, icons or tabs to change the window views allows for maximum display area for each window "as viewed".

It would be possible to allow a drag and drop function to drag items from one window view to the next by dragging the cursor over the tab to jump to the destination window. Hovering over a tab "while in drag mode" would not require a mouse click (as the mouse would already be in click position). It might also allow the cursor while in drag mode to hover sequentially over each tab with the window popping up, which may be helpful if the user wasn't quite sure where it was they intended to drag the items to. This permits maximum use of screen real estate.

A visual scratchpad (just like a clip board/clips/resources, but the contents are viewable) could be used, for temporary dumping (the user wanted them taken "from" somewhere, and can make decisions about destination some time later. A scratch pad also allows the complete removal of items from source, and then split them up over time for allocation to other destinations. Since the software already has these processes for handling clips, it would be easy to adapt it to include this scratch pad function. Multiple scratchpads could be possible.

The user could even have customised tabs where they might want to show a combination of smaller windows in the same tab view. In this way tabs could be used to quickly select what sort of view the program would be used in.

Customisation might also allow for example, the showing of the trackview but for different timespans , time zooms, and track combinations.

There could be the facility to copy one tab view as a start to making another customised variant. There could be the option to update keypoints, transitions and/or effects amongst all window views of a track. Or they can be kept separate till decisions get made later, and also be allowed to check out different scenarios of "mix". The mixes could be compared visually using a "viewer" for each mix, played through live. The keypoints for for each mix could be compared using a kind of a transparent overlay view so the levels and timings can be seen for the various mixes (with the differences being visually obvious).

 . -- ["Tree"][[DateTime(2008-05-21T15:41:00NZ)]]
== Tabs for programs steps that follow the workflow, and allow for future extension ==
The idea is to have tabs that show a view of the tools, as best '''''laid out for the process''''' that gets carried out. The tabs by default, are ordered in the order that the processes get done in in each project. the order is left to right and top to bottom generally, but may be changed for countries with different conventions. The views may or may not be customizable (as determined by the authorship of the respective process).

Processes may be '''''easily added in future''''''''''''''''''''''''''''' as the range of built in, or plugged in functions increases. Each step would have a familiar (style in keeping with the rest of the GUI)  appearance and be conveniently laid out. This allows for the program window to take up the '''''whole''''' screen, and easily flick from process to process. Each process is gets a full screen, and it cuts down the effort required to search for windows on the desktop.

The program and plugins would only take up one button on the desktop's task bar, so it makes it very easy to see all the other programs being used.

Not only may the view layouts be customizable, but the number of times they appear may be more than one, or not at all. So if the user wants to , say, view and work on two or more different parts of the trackview, then they can. This effectively gives the function of having a split view of the track, and it might be possible to have two (or more) connected to each other by a time offset (which could be easily varied). This would be useful for say, inserting a long clip. It would be a bit like the sparse timeline, but you can only see one end at once, though it is very easy to '''''"jump"''''' from one end to the other (or any other viewed edit location).

All the general program '''''menu items''''''''''''''''''''''''''''' would be '''''placed''''' above the tabs bar. All the process specific menu items (including what might be specific to "some" other processes), get placed below the tab bar, in the process window. Editing widgets can be of common design in each process - e.g. track fine timeline editing, track size. Methods of retrieving nodes designs, transitions and effects.

 . attachment:Screenshot-Cinelerra_nodes-view-tree-02.jpg
 . Notes on Node display.
 * The node situation is display vertically across the tracks on the timeline in trackview.
 * The node tab can be viewed in short form iconic mode, or expanded network-pipe view mode.
 * The node tab can be used in an edit mode, where the tracks can be selected as input, and output, and effects are added by dragging and dropping from a master list, or local project toolbox, or (right) click and choose what to insert from a drop down list).
 * The node tab is assigned a name (in the example above it is simply a Nxx number). Hovering over the tab name can show the description. The local toolbox/kit of effects is shown even when the '''''tab is displayed in short form (as in N17)''''' , and this allows easy drag and drop to insert and connect the effects. The short form display shows which effects ra ebeing used (and which of the toolbox are not), and roughly to which tracks they are being aplied.
 * The '''''edit mode''''' allows an input or effects "box"/icon to be (right) clicked on to open up the parameters to be altered. There can be an option to allow the alterations to apply to only that clip, the group of clips, or update the node set to apply to the whole project whwere ever it is used, or save as a new option set. An effect (the purple one with the tick) has been selected for adjustment in N16. Nodes junctions can be re-ordered, bypassed (set to null), routes split or deleted by clicking and dragging the connection lines.
 * The '''''camera and projector areas of the inputs''''' can be roughly set directly within the window of the node editor, to allow for fast general concept/sketch of the layout. But can be (right) clicked on to bring up an enlarged view for more accurate positioning (and settings) at a later stage of production.
 * The '''''node settings can be managed''''' by being saved, given a name, description and metatags to assign when assigning the nodeset, so that the effects can be easily applied time and again to clips/timestrips (drag and drop, or select from menu, toolbar, toolbox, drop down list - from full main set or local project kit).
 * The tab can be scrolled along the timeline, and the parameters in the node tab can be shown to vary with time.
 * The node tab shows which tracks are used for input and which are used for output - there is no assumption or forcing the upper tracks to have priority the lower tracks. Each node does not have to send their output to the same output track as other nodes.
 * More than one node tab can be active at any point in time. (a check would be needed that no eternal loops are created when more than one node tab is active at once).
 * The same node tab could be viewed at once in several locations on the timeline, just like keyframes, so the user can immediately see how the states have changed at each of the chosen points in time time.
 * The node tabs used anywhere in the project can all be created,edited, stored and managed in a view tab for nodes management, and could be quickly accessed by some tabs down the right hand side of the track view.
 * The video editor has '''''similarites to an audio mixer''''' . An audio mixer has inputs on left, effects on each channel running down, buses horizontally, and outputs on right. The '''''video editor is similar but rotated sideways''''' . So inputs are on top, effects are applied to tracks or subclips at times (can either be applied to clips/sets, or time positions), output are at bottom, and so '''''nodes/busses''''' which show the path from selected inputs to outputs would sensibly be vertical (as shown above). '''''Groups''''' (as in sets of tracks that get edited, "trimmed" or "moved" as a set from time to time as desired), are also connected vertically, but are probably better placed on the left side, where Cinelerra has previously allowed manual and temporary selection of (one) group (needed to be changed every time you wanted a different combination for a group, and couldn't be saved to easily return to a previous group). ecah groups could be a horizontal tab (choose which groups to be shown as tabs), or as a single column but column title area has a drop down menu to allow user to select which group is currently active. The group management/dropdown list also has options to save, assign name, add description, delete current group, create new group.
-- ["Tree"][[DateTime(2008-05-07T20:54:00NZ)]] updated [[DateTime(2008-09-01T18:29:54:00NZ)]]

== Transition, Levels or Effects Widget remains on top while swapping windows between track view and composer ==
Keeping the transition and effect window on top while changing and reviewing its effects and boundaries on the track view and composer allows for full screen views of both track and composer, without having to again click on the options window to make adjustments. It might even be handy to have a button that momentary toggles the view from track to composer (or visa versa) and back, which saves a search for the location to click in.

 . -- ["Tree"][[DateTime(2008-05-07T21:12:00NZ)]]
== Toolbars customisable for each stage of project ==
The user may have prefer transitions, effects, levels, and clips that they will be working with at different stages of the project. These could be kept "highly" available in a toolbar, so they are just one click away. This saves the browsing through folder views of plenty of stuff which is not of immediate need.

 . -- ["Tree"][[DateTime(2008-05-07T21:18:00NZ)]]
== Fine Resolution adjustment of any slider by means of mouse wheel ==
Fine resolution adjustment of any slider may be effected by using the mouse wheel. Maybe in conjunction with a key to represent finer or rougher resolution.

Hover over the slider and adjust the wheel.

 . -- ["Tree"][[DateTime(2008-05-07T21:25:00NZ)]]
== Trim raw footage and dump feature ==
When raw footage has been taken, it is handy and space saving, to remove footage that is not required. (stuff like rapid camera turns and, camera left running, etc). It is handy to be able to clip this out and dump it (into Trash to recover from accidental delete). It is also handy to be able to do this to the original file rather than re-run a new file. Keeping the time codes is useful, so the scenes can be re-laid on on a time scale. If the footage gets trimmed after it has been used, it would be handy to have utility that would update all the references made to it, so the in/out points do not get mixed up.

 . -- ["Tree"][[DateTime(2008-05-27T15:46:00NZ)]]
== Digital Zoom - Quality Advisor (for small adjustments) ==
I am not sure, but I would guess that; when the zoom effect is applied to a video track, there will magnification ratios which will have clearer (or more blurring) because they are either a whole number ratio of lines (or fractional). The time taken to render the zoom may also be effected by the zoom ratio. If this is the case, then it might help improve the quality of the render, to have the engine suggested zoom ratios that are close to the currently set user value (with info on the improvement to quality).

The user mighty be given the settings option to choose the level of quality improvement or minimal zoom change that they would like to be notified of the zoom effect on quality.

This function might be applied on conjunction with the "sharpen" effect (tests may be required to get the best results). Information on the subjective results could be collected by users, so that guesses for quality improvements in future, will be more confident.

 . -- ["Tree"][[DateTime(2008-06-06T09:58:00NZ)]]
----
= Track View =
== Track View Height ==
Let the user have more flexibility over the track view height. Some tracks can be set to minimal, others to visible (but basically iconic), others enough to see features, and one or two to good resolution. Some may even be blanked.

The track view height could be individually selectable , for example, by changing the "draw media" icon from toggle mode to drop down menu. The drop down selection options could include "don't show", followed by track sizes as per the drop down menu at the bottom of track view.

 . -- ["Tree"][[DateTime(2008-05-07T17:30:00NZ)]]
== Player (Composer) - Multiple Windows Viewable ==
The user might be interested in seeing the video of two or more tracks at the same time, to help synchronise what is going on with the before and after effects and levels.

This saves having to run the composer with track levels set to less than 100% just to get a picture of what is happening on (say) 3 tracks at once. Which saves a heap of work going through afterwards resetting the level between fades to maximum again - for several tracks - between marked labels.

If there is an easier way to "use" this kind of process, then it needs to be made more "intuitively" obvious.

 . -- ["Tree"][[DateTime(2008-05-07T17:23:00NZ)]]
== Player (Composer) - Viewable docked at end of each video track ==
One way to make multiple composer views available, is to allow each track's composer view to "dock" with the track at the end of the trackview. Each composer view may dock at the height of the respective video track. But if the video track has its audio tracks below it, the view could dock to the height of the Video and sounds tracks.

 . -- ]["Tree"][[DateTime(2008-05-14T17:23:24NZ)]]
== Track View able to be seen in "split views" - vertically. ==
The track view could be split in half vertically. The top could be shown on one monitor, and the bottom on another. The menu could be optionally shown at the top of each track view. For mixing of large numbers of tracks, but where they are grouped in sets that mostly do not effect the tracks outside the set, there could be buttons/tabs/icons that could activate the display of the selected set. So it easy to jump from set to set.

 . -- ["Tree"][[DateTime(2008-05-14T17:23:24NZ)]]
== Track View able to be seen in "split views" - horizontally. ==
When editing a segment or clip insert , the main point of attention is to the transitions at the start and finish. The video data in between are not part of the task. It would be handy if the start and finish regions could be displayed at the same time, and avoid scrolling along the timeline. It would make for easily checking that the "style" or other features are consistent.

Another situation where this is handy is when a clip is being split, but the split point is uncertain, yet all of the clip will be used. To be able to view the left and right side of the clip's split point and their transitions into the rest of the video, make sit easier to alter the split point. (It would also be handy to just have a slider for split point selection, which automatically ajusts the left and right views).

There may be times when the user would like to have multiple strips shown on the timeline - like yet to complete zones.

The track view could be split up horizontally into different time strips.

 . -- ["Tree"][[DateTime(2008-05-16T16:57:00NZ)]]
== Track View - quick meantime method to get "split views". ==
A quick way to get multiple track views right now would be to just have another track view instance. Another method might be to have another instance of the entire program running, but there might be a problem with file locks when working on the same file(s).

The window menu could have an option for "other windows", which it self would have the options to "make another window" and show any of the already made other windows (bring to the foreground) listed by "name". The "make another window" option could open up a submenu, which would allow the choice of which window is to be made "trackview", "composer".

There could even be the option for what "mode" the new track view window should be in when created, if there are alternative view modes (in future - e.g. audio mixer, node view, audio and video tracks, transition analysis, effects analysis, etc).

Option to dock the new view window below , above, left or right with the current window (saves repositioning and resizing).

Trackview window option to either show its own strip of time, or show the other end of strips that are being worked on in another ("master") view (so its displayed time will move as an insert (or transition/effect, etc) is moved.

 . -- ["Tree"][[DateTime(2008-05-26T10:52:24NZ)]]
== Track View able to be seen MultiTrack Audio mode. ==
The track view could have a mode optimised for audio track management, especially once synchronisation with the video track has been done, or is not an issue at the time. There might be a possibility of  of teaming up with the Audacity project and others for including code and features, plugins, etc.

One view mode for audio tracks in soundwave view. Sound effects parameters may be also shown )in summary) in this view. Another view for mixing desk channel view. Another view for detailed view of effects and levels applied to each track can be seen - possibly with feature to expand the view of a selected track for very detailed information - deatailed information may also be displayed as panels for each effect and numerical values change as the timeline is scrolled - panel boxes are automatically positioned so as not to cover up the track being concentrated on.

In the first stage, the view could even just behave as a window that encases the actual audio software. (not sure how it would be coordinated with the video, but since some situations require audio to be rendered separately, this method would work for those tasks anyway).

 . -- ["Tree"][[DateTime(2008-05-24T12:35:00NZ)]]
== Track View with Tabs. ==
The track view could have tabs at the top (on right hand side), which could be used for selecting the type of view to be displayed in the trackview window.

Views would include, current type of track view, node building view, audio track mixer view, view comments related to timeline, labels management (whether currently displayed in track view or not), live recording mix from multiple camera inputs, subtitling and transcriptions, translated voice tracks, project management for scenes, any other time related management tasks that may be developed in future.

So the user can select which timeline stretch(es) are shown on the bottom time line, and then simply click on the tabs to jump from one form of representation to another. everything is overlayed (in the same position).

Some folks might even enjoy using transparency if they are doing lots of jumping.

 . -- ["Tree"][[DateTime(2008-05-24T12:36:00NZ)]]
== Composer View shows markers for left and right sides of Trackview ==
It is handy to have a display on the timeline in the composer view which represents the left and right times displayed in the track view With the position of the pointer/insertion point also shown.

When playing a track through and stopping at some point, the point may not be visible within the width of time displayed on track view. The whole timeline is shown on the composer view. So seeing the width and location of the trackview timeline, on the composer would help to figure out whether you are in front of or behind the area displayed in trackview.

Another approach would be to have a full timeline shown in trackview below the zoomed in times, so that you always know where you are in the track. The full time line can display the range of times which are currently being viewed on the zoomed trackview.

This tiemline could be toggled using a "right/down" pointing triangle (like the "nudge").

 . -- ["Tree"][[DateTime(2008-05-12T16:09:00NZ)]]
== Slideable Magnified view of track levels ==
There could be an option to display a magnified view of the track view for selected tracks, that slides as the pointer is slides along the track timeline .

The magnified view could also permit the levels to be more finely adjusted. It could have extended sized sliders available for fine resolution adjustment attached.

 . -- ["Tree"][[DateTime(2008-05-07T21:23:00NZ)]]
== Insertion Line "CrossHair Frame" with Tools attached Trackview - get away from stationary editing to "on the fly" ==
The insertion line in trackview moves as the video progresses, and generally sits in the middle of the window. It currently only shows the position on the time line that is being played or edited. The insertion line could be used to show more information more closely at hand.

The levels in the "?" of composer view are noticeably changed during edit, but not during play. To get an idea of how the dynamic appearance of edits looks, the user has to go back and play through, stop, and make changes. This is good for fine adjustments at specific locations, but is laborious in the early stages where gross adjustments are needed , but the exact whereabouts and how much is not as important as the "overall? effect.

What would be handy for initial editing, is to be able to adjust levels "on the fly" while the video is playing (just like audio mixers). Then the user can come back and delete mistakes, move time locations and fine tune rough settings - knowing that the overall appearance will be similar to what they wanted. In this mode ,it would be an advantage to have the level adjustments close to the play point ("play point" = where the insertion line is on an armed track). It would also be an advantage to have a viewer close to the play point.

To assist with multiple parameter adjustment in real time, the keyboard could be used (e.g. arrow keys for pan/tilt, numeric pad +/- for zoom in zoom out, right Ctrl for brightness/right Alt for dimness, shift to make a label point for later).

 . The insertion line could be given the visual appearance of a "crosshair" shown in a supporting frame. The top of the frame would show the text information of the current label it is on, and the name of the previous and next label. The frame would include buttons to jump forward and back from labels, and keypoints. A panel attached to the frame would have full height level adjusters. There could optionally be a view of the video attached.
Unarmed and un-ganged tracks could have their section of the graticule blacked or faded out, and the arm and ganged icons currently only shown on the left of the tracker view window, would also be shown on the frame surrounding the graticule (absolutely help avoid not knowing which tracks will be effected by level adjustments. (In fact it might be a handy option to gray out all of the tracks which are not armed even if this "crosshair" is not implemented).

 . -- ["Tree"][[DateTime(2008-05-27T11:32:00NZ)]]
== Insertion Line "CrossHair Frame" with Dockable Tools attached in Trackview ==
Below is a concept visual for some features that have been mentioned. They are made available in dockable modules. So the user can choose where they want them and in what order. They can be dockable to left and right sides of track view (even on the outer edge of rhs) , and each other along a track, and with adjacent tracks or distant tracks in a "set".

The cross hair dock module is shown on the rhs. It has a magnifiable view of the timeline which is adjusted with the vertical slider, by toggling the magnifying glass icon (in time magnify/stretch mode the slider has a black knob). To scroll the crosshair along the magnified time line, the lower icon (with two arrows) is toggled so the slider (which has a white knob in scroll mode) can be used. When playing, the track passes under the cross hairs from right to left, so it is easy to see what is going on with the cross hair located to the right - this means that what passes out of view from the track, will soon appear in the magnified view.

The next dockable module to the left is the levels module for controlling the camera and projector sliders for that track. The key letters have been chosen to help with easy rapid increase/decrease type entry. The left hand controlling the camera, and the right hand controlling the projector. The blank space below the sliders could be made available for information on the effects, and maybe even some important effects controls - or can have information about the labels relevant to the particular track - or have keypoint management buttons (like make a new set of keypoints here, with the current "interpolated" values as a start). This panel may become hidden since it only gets shown when the overlays button in the controls at the left side of trackview is activated (downward pointing triangle). A handy button to have in a module would be to enlarge the view, by treating the module combination as a temporary new window for close up viewing and editing.

The next two modules to the left are the camera view (left most), and the projector view. There is room for about 7 buttons - one of which could be a "force this thumbnail view to be shown on composer view" type function, so there is a quick way to get a magnified view. The panels below are available for more buttons or information presentation, and maybe "comment" management. The bottins on the right side of the display could be used for activating the X,Y,Zoom levels for display, generating a set of keypoints for the camera or projector, etc.

A similar projector module can be shown below (or above) the docked tools , which shows the rectangles and contents for the combine projector views. Some uses that these features are useful for are ;

 * searching for suitable synchronisation points on each track.
 * fine adjustment of keypoint levels.
 * on the fly editing, changing levels roughly while playing, without need to stop.
 * concurrent viewing of source and product (camera and projector)
The track can be played underneath the dockable cross tools, or they can be dragged over the tracks. Though several have been shown, it should be possible for the user to assemble their kit of tools for the crosshairs, which can then be dragged to "any" track at any location, zoomed in, or played under, and all tasks done. Then quickly drag to somewhere else - everything, full kit, close at hand (a bit like the magnifying glasses with torches built in).

It might be possible to have more than one per track, so the end points of a stretch of video can be worked on, withou having to jump through several labels, or remembering where to "go to". These tools would act as a means to identify areas that are "being" worked on. Very easy for the user to "park" a task and work elsewhere, then come back.

 . attachment:Screenshot-Cinelerra_trackview-crosshairs_tool-other_way-synchro_mode-undocked-tree-02.jpg
'''Notes on Mouse Ergonomics'''

1) In the GUI shown above, the buttons in the small camera and projector view are small. They are clickable, but fiddly. These ease of targeting them is improved, by making use of the fact that to their left are'''''"nearby regions that do not need to be active"'''''. The area used to detect the cursors vertical position, can therefore be extended well towards the left of the buttons. This allows for horizontal inaccuracy of the mouse, while concentrating on the targeting the vertical position.

This concept could be applied to other situations where unused space is near where active space is tight.

2) The sliders are as thin as the bottons, but instead of being targeted for a temporary click, they instead have to be hovered on while dragged horizontally, or the mouse wheel scrolled. Any slight vertical drift, and there could be frustrations. The problem is alleviated by clicking on the slider, which then permits vertical motion 1 (or 2) sliders width above or below the slider, as still being held for the slider that has been selected. When the user wants to move to another slider (even the next one), they must move 2 (or 3) slider widths away to release the cursor from being "bound" to the slider they had previously clicked on. ''' '''

'''Note on keyboard ergonomics'''

The letters for the keys for the sliders are arranged for left (camera) and right (projector) hand keyboard use at the same time. Two fingers of each hand are used, one finger for increase, the other for decrease. The hands can be moved up/down the keyboard from one row to the next, to change from horizontal/vertical/zoom sliders.

. -- ["Tree"][[DateTime(2008-05-28T23:05:00NZ)]]

== "Voice" comments inserted using labels "on the fly" ==
Managing labels often involves hitting the make a label button (with the mouse kept on aim of the button, while viewing video). Banging away, making labels for events of note. Then coming back and slowly going through (statically) and''' trying to remember which label was for what '''- "Was this where I was going to zoom out or pan left?" or "Was this where I was going to shrink the projector to insert view over another track?". It can get confusing fast.

There are not many people who can type comments like this as quick as a video plays.  But ... they CAN talk almost as fast. So being able to '''record "Voice comments"''' would be really handy. And not too difficult considering the program does audio recording anyway.Labels could be used to associate a recording of voiced comments with events on the track. The program could definitely associate isolated talking with a label, and also make a best guess at associating a sentence with a label during constant talking. Otherwise the sound track can be recorded continuously (during the uncertain strips), and reviewed later by the user who can then manually edit the sound track to associate the specific comments with respective labels.

The voice comments could be transcribed (or voice recognised) to convert to text. But it might be that transcription never gets done, if voice comments are found to be very convenient - why?! Because the voice comments could also be played back while "reviewing" the mix, or scrolling the time line, or automatically played when hovering over a label.

This approach leads to an increased usefulness of the label/comment system, so that it might be used as a kind of '''"micro - to do"''' list (with "yet to do", and "done" reporting functions), or assessment evaluation.

More than one set of labels with matching voice comments could be made. Either same person as project progresses, or several people. It would be possible to play the sound tracks back (in stereo or multi-channels) to get the effect of a brain storming session or conversation. Comments about comments could also be made so it acts as a "running commentary", and highlights topics that the team may wish to hold some real discussions on.

 . -- ["Tree"][[DateTime(2008-05-27T12:21:00NZ)]]
== Voice "speech to text" enabled features. ==
Voice comments, and voice commands could be made possible by using any/many of the speech to text FOSS programs. There could be an option to keep voice comments sound form, even through text is generated. This would be useful for checking that the automatic transcriptions were correct, and also acting as a playable sound, when ever the comment is displayed, or command completed. This allows the user to interact with the program without additional need for "hands/fingers", adding another dimension to control and ease/speed of use.

 . -- ["Tree"][[DateTime(2008-12-11T18:30:00NZ)]]
== Track View with scroll compare. ==
The track view could have a function similar to what spreadsheets have - select a line (track) and be able to scroll the other tracks vertically. This would allow the rapid comparison of track content, with the track that has been held fixed. A sort of move up/down function, but easier for the user to follow how the program is responding.

The track being fixed could remain where it is, but all other tracks slide "behind it", either up and down or wrapped top with bottom. Clicking out of the compare mopde would return tracks to their initial position (except for any that get selected for relocation).

 . -- ["Tree"][[DateTime(2008-05-28T18:31:00NZ)]]
== Track View with camera rectangle on track thumbnail. ==
The track view could have the '''''rectangle for the camera frames shown on the thumbnails for the "input" tracks'''''. This would assist the user to see "at a glance" if there were any gross situations of subject being out of frame, or too small in the frame.

The '''''"output" or "mix" track could have the projector rectangles''''' for the various input cameras that it is made of. Maybe colour coded, or line styled so it is readily apparent which input camera is  being projected to where, in the one view. A similar representation could be shown in composer, when looking at the "output"/mix track(s).

 . -- ["Tree"][[DateTime(2008-05-29T13:29:00NZ)]]
== Track View with facilities to accommodate multiple output mixes (e.g. 16:9 and 4:3). ==
The track view could save time on mixing for different output formats, by having '''''systems that allow for creating several output tracks at once'''''. Say one for 4:3 and another for 16:9, and another for iPod. For some digital formats, there is no need to consider "safe" zones, because all of the frame is always shown. So a mix for "fuller" pictures can be done.

'''''Easy ability to mix and match (convert and insert) 16:9 format with 4:3, so the two can be used side by side'''''. The home and business TVs and Video Monitors are slowly moving from 4:3 to 16:9, and there are a number of situations where dual format would be advantageous.

The ability to mix 4:3 and 16:9 (and others), would require the cropping and/or insertion of black/white/background/transparent areas. In some cases the picture may not be being used for full frame, but used for an insert. One way to do this is to determine what is to be inserted and then where it goes. But another way is to determine what area is going to be used in the destination, and then check what is being used to fill it from the source. Because of the different geometries, it is difficult to draw an area in the source frame, and know how it will look in the destination - so a corresponding shape is needed in the destination. The shapes may be controlled either at the source, or at the destination - which ever the user chooses, with the corresponding adjustment made in the other non-user-adjusted frame.

This method allows the combination of all the functions of re-proportion, zoom, crop, overlay/insert to be done all at once. This reduces the complexity of the steps (e.g. if using nested effects), and possibly reduces errors/noise due to repeated calculations on non-original data. It doesn't require any preconversion of one video format to another, so allows the editing process to begin immediately - just load the tracks. Most of the calculation gets left to render time, and the calculation only needs to be done where the track material is being included.

 . -- ["Tree"][[DateTime(2008-05-29T13:34:00NZ)]]  also was added to [[DateTime(2008-09-12T17:19:00NZ)]]
== Facilities to handle differences between PAL/NTSC ==
 * One-click conversion between NTSC 29.97fps, PAL 25fps, Film 24fps, etc, compensating for dropped frames (eliminate/reduce judder, etc) and so on
 * One-click conversion between NTSC 720x480, PAL 720x576 source material (e.g, PAL pixels aren't square)
(Somebody, Sometime)

== Track View with drop down view of nested clips, scenes and projects    *** ==
The track view could treat each track as a view of its components. And  '''''just like the folder tree view'''''''''''''''''''''''''''''  on the left hand side of a file manager, you could click on a track and see a drop down of the sub-components of the track (like sub folders). These in turn can be clicked on to see what they are made of. So this works like a file manager, in track view, because  '''''one of the main functions of track view is to be a ''''''''layout manager'''''''' for the clips'''''. So this grabs an intuitive function from one manager and makes it available in a similar way in another (track) manager.

Each item could be viewed (as a first implementation), but the aim is to be  '''''able to edit each item'''''. When edited the user could be given the choice to edit those components, as limited to the current project, or to make the edits replace the original, or create new updated "versions" of the originals. A right click on an item could display all the metadata associated with the item and choices on how the item and edit should be "managed".

To view the components for a stretch of time, then just select the time on the track (or sub-item). To view the sub components for a component on the track, just right click on it.

The drop down could be set (by default) or chosen (by right click context menu) to '''''show video thumbnails ''and/or'' metadata summary ''and/or'' selected edit/effects levels'''''. The metadata might include the length of current edit of the clip, details of the original, other projects the clip is used for, information about how the clip was made (camera, crew, location, cost, etc), information about what purpose the clip is mostly for (project, archive, the commissioning customer). The user could choose which metadata items are to be displayed, just like the columns to display file parameters in a file manager.

Additional features of this system could include, displaying locations (and dropping down) all components that are the result of a '''''search criteria'''''. e.g. show all clips from a subcontractor, or made on a particular camera.

When a component on a track is a composition/blend of more than one other component, then the user could have the option to show each subcomponent separately below the others.

The drop down is '''''intuitively suggested by the use of a "triangle arrow"''''' on the track ends, component ends, ends or middle of selected timespan, and as an option in context drop down menu when right clicking on a track. Right clicking on a track would sjow menu options which include ;

a) Show components for this track

b) Show components for this component (the current component would be highlighted)

c) Show components for currently selected timespan

A similar idea has been shown below, but the drop down function in that method, happens at the end of the track, and would probably have difficulty showing what happens for tracks, where the situation changes with time. The suggestion above has the drop down able to be done at "any point in time along the track", which allows for more universal application.

http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming/Proposal.AkhiL?action=AttachFile&do=get&target=AkhiL.proposal.png

viewable at ;

http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming/Proposal.AkhiL

 . -- ["Tree"][[DateTime(2008-09-01T19:02:00NZ)]]
----
= Timing =
== Timing Management in Menu ==
All matter to do with timing and synchronisation, could be made available long handedly from the menu, as well as conveniently using right click mouse (or other assigned keys). This would include Nudge track number/name, time shift, audio or video delay for each live recording track (so that the audio and video will match up as recorded ( a simple field test measurement window would be very useful)(plus and estimator based on distance from microphone to subject and speed of sound (330m/sec).

 . --["Tree"][[DateTime(2008-05-07T20:09:00NZ)]] .
== Inter-Track Synchronisation Features ==
Matching sound track to visual track events (clap board) is a really practical feature. No more listening (hoping your PC's audio delays are not great). Just look for the drum smash, hand clap, plosive mouth movement, and you know where you are. Label the instant on each track, click "synchronise on the menu (or right click option), done. Make it able to do for many tracks. Make it able to to at many points along tracks, so it can detect if the tracks have got out of synch or have not the same scene lengths.

Needs options on how to have overflows at ends of projects, and scenes/strips/clips within project tracks.

 . --["Tree"][[DateTime(2008-05-07T17:35:00NZ)]]

== Video and Sound track Synchronisation Features ==
==== In Studio Use ====

There may be different delays in audio an video paths when recording, rendering(live), and output to files, and playback on devices (e.g. video DVD). These delays could be calibrated. When watching a video that is being rendered live, on the studio monitors and listening to it, the technician may adjust the sound track timing so everything is in synch. However this timing could be totally out when the rendered tracks are recorded onto DVD, and played back on various other DVD players.

Needs options to calibrate and set the respective delays of components (software and hardware), so these can automatically be applied to the process that is being done with the tracks. Initial implementation may just rely on the operator nudging the tracks and noting which offsets give the best results (for record, render live, play rendered track on Lumiera, play rendered track on other players on computer, burn to DVD or VCD and play on player). The experimental results of these tests could be included as a "first guess" setting(s) in Lumiera.

An advancement on rough guessing, would be top use a device that generates sound and light at the same time, so it can be used as the synchroniser. Such devices may be electronic, a firecracker, or mechanical (like a metronome, clock pendulum, bell ringer).

In the case where Lumiera may be used in conjunction with performance control systems (or is used for the actual control or trigger of control), then the devices for detection and calibration could also be used to define the delays related to the performance triggers and the resultant reactions. And the manual reaction time of the operator who queues to events based on what he/she sees, or the delay of machinery that has automatic detection of the trigger for the performance effect.

==== In Field Use ====

When video is taken at a distance from the sound source, there is a delay for the sound to reach the camera. This delay may either be because of the physical distance the sound has traveled through the air, or because of the number of devices the electronic signal has passed through (analog preamps, A/D converters).

When videoing in these (field use) situations, there may need to be an offset applied to the sound/video relative to the (chosen) master track (used for timebase synchronisation).
Offsets would also need to be applied to video of objects that may be responding to the sound which are at a distance from both the camera and the sound source, yet are to be shown in synch with the sound as "at" the object. e.g. shots of audience at rock concert, by camera midway between stage and camera at back of audience, to be synchronised visually with sound as "at" the stage. The camera at back of audience, is also sychronised with sound as "at" the stage (either by delay due to electronic feed from micksing desk (NOTE the X is not allowed because x-i-n-g is not "allowed in this wiki" - took over an hour to figure out why the edits weren't working, plus the protection timing system doesn't seem to be so accurate now. "se la vie"), or physical delay by sound traveling 100m passed the audience = 0.3 sec delay).

Similar detection, calibration, and setting systems can be used .

==== Spacially zoom of sound when video is zoomed ====

When the video zooms in (or away) from the subject, the sound is almost always (currently) not adjusted to provide the associated audible perception.
When zooming in (out), the sound should be adjusted to match the closer (further) distance to the subject.
For example, a zoom in of 3x should be matched by a time delay after the sound was created of 1/3rd (the time delay would have to be measured - or guessed by delay (seconds) = distance (in meters) / 330. 

Note the time that the subject makes the sound, or the time that the recorders record the sound, may include delays due to other causes than just the distance, the time adjustment used for zoom would only apply to the delay due to distance, with the other delays being removed beforehand. Delays due to other causes are likely to be negligible once the distance exceeds 10m.

The loudness would also need adjusting (proportional to distance squared - on ground, or proportional to distance cubed in air above ground or water). May also want/need to simulate mic (or ear) clipping if it is desired to sound like it was up that close. Maybe also add wind rush. Maybe also accentuate frequencies which get attenuated more than other over distance.

3D sound systems may make use of the ability to "reposition" the sound audibly to represent the new apparent location of the observer relative to the subject.


 . --["Tree"][[DateTime(2009-01-03T11:59:00NZ)]] .


== Bulk Shift by time/frames ==
Able to select different parts of the same or multiple tracks, (group them, name them, save their particulars, work on them,) and shift them all in the time line by a set amount of time or number of frames. Select the areas, then scroll a slider, mouse wheel, enter a number,etc. Could be used for matching up already matched segments with other already matched segments, all at once.

 . --["Tree"][[DateTime(2008-05-07T20:07:00NZ)]] .
== Nudge Keypoints ==
 * Nudge or shift (selected) keypoints, groups, relative to track content, or "with" the track video/sound.
 * Nudge the track on the timeline display, so actual points in time (or as played) are shown above each other for all tracks.
 . --["Tree"][[DateTime(2008-05-07T20:08:00NZ)]] .
== True time on tracks in Trackview and Composer ==
The number of frames is and exact count. If the user is able to tag a frame and assign a real time to it, then the rest of the times on the timeline can be calculated. The real world time can then be shown (either as local time, as per the users clock - with error offset from actual time, universal time). Good for figuring out the times of other events/scenes. Good for using as an estimate of where to add a clip that was taken from a different camera at a different start time.

 . --["Tree New Zealand"][[DateTime(2008-05-09T14:05:00NZ)]] .
== Time Calculator ==
It would be handy to have some calculation features to help manage time.

Calculate current blank space in timeline. Using labels calculate total amount of transition/effect/inserted video time yet to finish working on.

Click on two points, and calculate time between, time from start, time to end, add time since start to local real time at start of recording to extract real local time at the time of event.

Alternatives include using different time units (e.g. frames).

Plot labels verses elapsed time (labels used as event markers).

 . --["Tree New Zealand"][[DateTime(2008-05-24T13:10:00NZ)]] .
== Time and Motion Tracker Calculator - velocity and acceleration ==
With the ability to measure time, and using the motion vectors from the motion tracker, the velocities and accelerations can be calculated.

In the first instance, only the angle moved through the field of view can be used. But if the distance from the camera is known (or guessed) then reasonable estimates of the real velocity and acceleration can be made.

This would be very useful in a number of uses including;

 * using the video to extract rough estimates of distance, velocity, and acceleration (athletics, vehicle studies)
 * videoing of moving objects and looking at how they behave through movements related to the forces they experience.
 * 3D animations that use real physics engines to generate the objects motion and shape, when experiencing the same motion.
 . --["Tree New Zealand"][[DateTime(2008-05-24T13:15:00NZ)]] .
== Footage and automatic scene placement feature ==
When inserting footage into a project, the time stamps on the video could be used as first guess for how far to move each scene along the time line, to match up with other tracks, or leave gaps for inserts from other tapes. A facility for the user user to manually adjust the time would be helpful in the case where tapes were downloaded to the PC from an analog source at a time other than the real time.

 . -- ["Tree"][[DateTime(2008-05-27T15:52:00NZ)]]
----
= Editing Mode features =
== Key Point Manager ==
Saving the settings for sets/series of key points would be handy for repetitive tasks. Just paste them over a track for an immediate insert size or what ever. Ability to stretch or compress it in time, and match up to time events with out risk of changing the level. Or change the level without moving time. Have sliders for all required adjustments available near where you are looking (widget?). Save any number of presets sequences.

 . -- ["Tree"][[DateTime(2008-05-07T16:44:00NZ)]]
== Key Points able to be shown for parts of a track ==
Sometimes the levels that need to be viewed on a track, are different for different parts of the track, and different tracks. For example the camera in one track is being adjusted, while the projector in another is being adjusted, but also the first track's fader is being adjusted in the time up to (and maybe overlapping) the camera adjustments.

 . Currently all things must be shown in all tracks, if any of them are needed in any track. This means that the level lines at keypoints can become visually very congested, and the user has do do a lot of toggling the overlays/assets. The problem can be made less confusing, save time, and chance of error, by making the keypoint management system a bit more flexible. The added flexibility may add to confusion for beginners, so could be made available under advanced settings. The management system would need some way of displaying the states for each track, and which ones are "live" when the user is at each time segment in each track.
 * Assign displayed assets/overlays independently for each track.
 * Assign displayed assets/overlays as required for different segments in any track.
 . -- ["Tree"][[DateTime(2008-05-14T08:59:00NZ)]]
== "Generate KeyFrames" icon made visible "close" to the viewer where keyframes are being generated ==
When setting up keypoints and adjusting them as you go, it is necessary to frequently toggle between auto keyframe generation, and adjustment. Because of this, it is also possible to forget to make the toggle. To correct this can mean some careful "undo"-ing is required. It is better to help avoid the mistakes. The icon could be made visible closer to where the activity is actually being done. It is best to have it right in the user's face in the window they are actually working in. It also is immediately accessible and doesn't require clicking around to bring another window to the front (make the toggel) then go back again (and again .... and ...).

The "Generate Keyframes" state icon is shown in the composer AND could also be shown in the "?" window (and maybe assets/overlays).

 . -- ["Tree"][[DateTime(2008-05-14T09:12:00NZ)]]
== The "?" window to show parameters for both the projector AND camera. ==
The "?" window shows only the project OR camera information, but never is all the information available at once.

Having a separate "?" for camera and projector would be handy. Or having a "?" window that has the option to show the "other" aswell.

 . -- ["Tree"][[DateTime(2008-05-14T09:23:11NZ)]]
== function to Generate (or fix) a set of keypoints at the current position ==
Often it is necessary to create a set of keypoints at a keyframe location that either match (or may need some slight difference) the next set, or the last set. This is done when having set general tracks levels, the user then wants to go and "tweak" segments within the timeline. So basically the ends of the tweaked stretch need to be fixed to the track default/local current setting/or the interpolated value currently depending on the next and previous settings outside the segment. The following keyframe edit functions would be handy ;

 * copy keypoints at this keyframe , from "source".
 * the source can be "previous keyframe settings for each level (which may or may not be at the same keyframe)", the "next keyframe settings for each level (which may or may not be at the same keyframe)", the current position's interpolated keypoints, the current position's keypoints based on what they would be using the settings before and after the current segment (this is a more complex option).
Another approach would be able to select an length of the timeline, and keyframes at the ends using the options for source selection, above.

 . -- ["Tree"][[DateTime(2008-05-14T09:32:00NZ)]]
== Labels and In/Out point markers for different purposes - Multiple with flow control for loop sequences ==
It is frustrating doing work where the IN/OUT markers have to be moved to go from loop play to render to another loop play. It would be really handy if the IN/OUT markers could be made in pairs, in large (unlimited) number, assigned their purpose (e.g.loop play, effect, level adjustment, etc, and more). It would also be handy if labels and keypoints could be not only labeled, but grouped, with group names.  Then just like gang selection for track groups, labels and keypoints could be made visible/invisible, editable/fixed, highlighted/dimmed, differentiated by colour. In/Out points created for play or render could be used for loop play, but could also be told to play in any selected order - and again in any other selected order - again and again. This would be helpful in comparing the impact of "sequences of clips" without having to manually create each sequence. Each sequence of In/Out point groups could also be made to loop.

same goes for In/Out point pairs for clipping/editing, easy to "undo" with just one step. Apply effect to all selected pairs/ everything not selected, try it, adjust it (all), undo it.

 . --["Tree"][[DateTime(2008-05-07T19:16:00NZ)]] .
== Play Sound while moving around the timeline ==
Play Sound while moving around the timeline when using the mouse.

 . --["Tree"][[DateTime(2008-05-07T19:17:00NZ)]] .
== Customisable Preset Groups (or gangs) of Tracks and overlays to edit ==
It is often necessary to arm or disarm several tracks in "groups" while adjusting levels, and camera or projector. Typically for the main picture, and separately for insets. It would be handy to just have to click one button to "select" the grouped set. A number of buttons could be available for customising which tracks and which levels and controls get switched. These could be placed at the top of the left hand side track controls. A different method (which could also be optionally available) would be to have a window similar in vertical layout to the assets and overlays window, but would extend horizontally to show which overlays are active/armed for each group. This could be made active to enable "group armed management".

Another feature that could be added is to group the sliders that get effected and choose whether they get adjusted by the actual amount, or a percentage, and if they increase together or some decrease while others increase.

For locations where the keypoints are fixed in time, it would be handy to have sliders pop up At the keypoint, for each keypoint that is currently armed. The sliders could be horizontal or vertical, but would provide greater visual and mouse resolution than the track height. This would allow more tracks to be visible, the time line to be more condensed, and yet control would be more accurate easy and comfortable.

The user might choose which groups of tracks to have displayed, or which tracks rend to which.

An example is shown in one of the images near the bottom of this page (Possible GUI ??)

 . --["Tree"][[DateTime(2008-05-07T18:49:00NZ)]] .
== Overlays, Crops, Camera, Projector, Masks. Also same for Titling ==
These are all handled differently as far as the way their areas are selected. But it could be made so that they all share the same full range of area selections. Rectangles of fixed ratio, free ratio rectangles (for camera and projector - aspect ratio of subjects is maintained, auto cropping is done), free multiple point shapes, all with feather options could be achieved. PNG or other transparent images (or means of determining transparent areas) could also be "logically" combined with the Task (Overlay, Crop, Camera, Projector, Mask) to provide extended functions in the way the images are combined. I know you've got some great opportunities with Blender. This will be fantastic!!! But please keep a simple novice pathway for the use of these features, so people can get accustomed to the production pathway, without getting lost in its intricacies.

Other shape drawing functions (circle, oval, rounded corner rectangle. Copy mask and translate (can drag already), and rotate.

Also the crop function is not "intuitively" apparent to the user whether it is going to crop the camera view or the projector view. I haven't used it yet, and have had to read instructions to find out, but it sounds like it crops in the projector view only. Confusion would be removed, iif when the crop function was clicked on, the projector view icon was highlighted (slightly - not as much as when actually adjusting it), and the projector rectangle is shown. This way the user can see, learn, know, and be reminded more exactly what mode they are in when they are cropping.

If cropping can only be done in projector mode, and the projector icon is made to be highlighted, then it would also be possible to make the cropping function available in camera view with the camera icon highlighted.

Also same for Titling, where other graphics programs may also be used. An easy way to go in and out of the graphics program for finer adjustment of shapes and properties would be handy. Or at least to make an adjustment in the graphics editor to a file, and have the result immediately influence the images in Lumiera (say watch the changes in composer window - then render a test strip).

 . --["Tree"][[DateTime(2008-05-07T21:33:00NZ)]] .
== Matching colours and line styles between overlays on timeline and composer windows ==
Different colours are used for X,Y,Zoom, but these colours are not used for the camera and projector views. If the colours were used for the edges of the boxes for X (sides), Y (top and bottom), Zoom (an arrow perpendicular to the edges of the box), then this would act as an additional visual prompt (with meaning) - adding to the intuitiveness.

--["Tree"][[DateTime(2008-05-14T09:25:00NZ)]] .

== Overlays and Lines on tracks and Composer ==
Allow a greater and user selectable range of colours and styles (thickness, and dots) for the levels and boxes on tracks and in composer. This way the user can clearly distinguish between the effects. Colours for X,Y,Rot and styles for camera, projector, Motion .

 . --["Tree New Zealand"][[DateTime(2008-05-07T21:33:00NZ)]] .
== Test Strips and Series of Test Strips ==
"Give me the first X seconds or minutes of the project so I can see what it will look like and estimate more accurately how long it will take?" "Will I need more resources, time, expenditure to reach targets?". Run a series of test strips for timing and results tradeoffs. Done with manual settings, or generate set based on x% more and y% less for various parameters. Show the strips, user assigns evaluation rating, and can weigh up the best compromise. Use for in house drafting, production test runs, and final product. Save and share settings.

 . --["Tree"][[DateTime(2008-05-07T21:33:00NZ)]] .
== Layer mode for Track View ==
The thumbnails shown in the Trackview are typically the full size of the original. It would be handy if there was an option to show the thumbnails of the camera, or projector as the thumbnail instead. This would allow the user to "see" what their camera or projector settings are. No need to interpret x,y,z, levels.

Also where a track is overlayed by another, there could be an option to "show layers", or in the case of a final track an option to "show (which) layers (tracks)" in the full mixed track. There could be an option to "not show" composer view updates while rapid scrolling through timeline in trackview. Saves processor load. The display of playing tracks (overlays) could be shown on the right side of the composer view, where they could each be toggled on and off, instead of having to return to trackview. This allows features and the feel of "Graphics Editors" that use "Layers". Note that if multiple composer views were able to run, then it would be possible to check "sub mixes" before combining to a total mix. Example Composer view of full camera view of track 1 with effects applied. Same time have another composer view of Projector view of track 2 with its effects, plus box where the other view will be inserted. Check run through both at full view "at once" to make sure each is OK. Then combine for final checks together.

 . --["Tree"][[DateTime(2008-05-12T16:35:00NZ)]] .
----
= Automatic Assembly and composition of Media components and clips =
== Flexible and automatic Project - "Importance Levels" and "retiming slippage" - Gantt methods (Gaant or Gannt) ==
For video that has to "fit in to" or "extend out to" time constraints, it would be handy to have '''''a tool that assists in the stretch/compress of the whole project'''''''''''''''''''''''''''''. This would involve the removal or addition of clip end '''''based on predefined priority'''''. This can be achieved by using a clip placement method that does NOT used "discrete (or fixed) ends". Just as a fader can be used to blend in to another clip at the point where the priority of viewing changes from the earlier clip to the later, so it could also be possible to use a "fader like" control that relates to the "importance" of the frame (rather than its "brightness/viewability").

So when a clip is inserted, the user could assign an 'importance fade level' in  over time for increasing importance up to the "must show level", and at the end of the clip the user could assign a decreasing fade down to the level of "must not show". The slopes could easily be different.

For convenience, the '''"importance fade levels"''' could be set as early as the time when the '''live recording''' is being done (using mouse slider, or some human interface device e.g. midi, joystick), or '''during the initial preview, and clip making process'''. The "importance levels" could be assigned and  recorded for more than one person, and for more than one purpose/project. The average could be calculated, or "agreeance/popularity" used to automatically select priority program content. This might start with junior staff doing searches of content to select anything that might be "relevant", and finish with editors/directors prioritizing what is "really important".

In the case where several angles are taken at the same time of the same event, the "Importance Levels" set when viewing/recording one angle, could also be copied across to the same times of the other angles (these could be edited later, and/or have additional importance level sets created). This way the importance of what is happening in the content can be rated at once. The importance related to best angle can be rated in another different "importance level set".It might be handy to be able to attach notes to the "importance level" set, so decisions can be explained, and "definitely include/exclude this" type flags can be used.

The user could then grab the whole project, or sub-areas, and stretch or compress their timeline. The value of "importance" at scene change would decrease for all selected transitions, as the time for the selected sub-area gets stretched. And conversely the value of "importance" at scene change would increase for all selected transitions, as time gets compressed.

It could also be used to show the minimum importance level of the project for the clips in the timespan. This could be used to estimate quality of content, expected ratings by viewers, identifying sections of the program that need either more important content (or failing that - more impressive content).

The methods for prioritising here use time slippage concepts from the Gantt project management methods, but the suggestion here is to also have a method to "weigh the priority" of the end of one strip with the start of the next (also can be relative to all starts and finishes).

Not only can the "importance levels" be used for first guesses/best fits for transition times between clips, but they could also be used to do quick grabs of clips for previewing when starting another project. Searches such as , get me everything with an importance level of more than 80% on the topic of dah-dah, from such-and-such project and those whatz-it series. Automatically generate EDLs (SMILs) for first drafts.

A major benefit of recording these "importance levels" (for different people/projects/purposes-parameters) is that for all the many 100s or 1000s of clips that a staff/team need to deal with, this helps manage and remember (for ever) where the relevant and not so relevant parts are. It no longer needs to be recallable from one or other person's (busy) mind, and becomes a shareable and shared resource. (It may even help with training of junior staff - because they can see where the priorities have been set - without needing to have the senior staff give them one on one when ever a decision process needs to be explained.) .

(The importance fade levels could be represented as level lines in track view, or as intensity or brightness of the thumbnails. This way it is clear to the user as to which tracks have been determined as higher priority at any given point on the timeline.)

 . --["Tree"][[DateTime(2008-05-26T09:28:00NZ)]] .
== Programmable Movies - the "Soft Cinema" Project for automated program creation ==
Soft(ware) Cinema is a dynamic computer-driven media installation. The viewers are presented with an infinite series of narrative films constructed on the fly by the custom software. Using the systems of rules defined by the author, the software decides what appears on the screen, where, and in which sequence. Clips are selected from a database of clips; it also chooses music tracks.

http://www.manovich.net/cinema_future/toc.htm

--["Tree"][[DateTime(2008-09-26T01:03:00NZ)]].

== Programmable Movies - "KORSAKOW-SYSTEM" Project for automated program creation ==
"They are''' interactive'''- the viewer has influence on the film. They are '''rule-based''' - the author decides on the rules scenes relate to each other, he does not create a fixed order. They are '''generative''' - the order of the scenes is calculated while the viewer looks at a Korsakow-project. Korsakow-projects can only be viewed on a computer. They are delivered via internet-streaming, DVD-Rom or CD-Rom."

The scene clips are retrieved from a database of clips, and assembled according to the rules. Several assembly orders can be created (at once) and viewed.

http://www.korsakow.com/ksy/index.html

Created by Florian Thalhofer at  http://www.thalhofer.com/   who is teaching a course at http://www.uni-leipzig.de/~dll/  Leipzig University.

This is not open source because it depends on Adobe Flash. But it is free. It works on some Apple Macs. There appears to be no linux version available at present.

Opportunities with this project include ;

1a) use a substitute flash file player (and may be editor). Though this system is for assembling clips as per rules, not so much the editing of the clips.

1b) may be amend the code so that other file types can be used as well as Flash.

2) use the code that runs the rule system. set it up as a plugin. share the improvements that get made to the rule system back with Florian.

3) The user base for the Korsakow system could be keen to use Lumiera (and any associated utilities and plugins). There are over 250 projects made with Korsakow, and a German Literary/book project is using it to automatically generate presentations/compilations of the books in the collection/library.

4) the method of generate precis clip views would be handy as a method to quickly present search results according search rules, guided by presentation preferences/priority.

5) The user base for the Korsakow project are both artistic and technically proficient, which could be interesting if these talents get keen on Lumiera.

So using some code sections from this project could be a good idea - may be not priority.

But in any case, getting in touch with the Korsakow-Project user base could result in more Lumiera interest - maybe testers, code writers, word of mouth, etc.

--["Tree"][[DateTime(2008-09-26T01:07:00NZ)]].

== Project Layup/Sketch/Storybook/Draft approach facilitated ==
Planning of a project at the concept stage would be helped by using the video editor to sketch up the general flow, and optional scenarios.

The content might include scan of hand sketches, el cheapo mockups, script reads and representative ad hoc ad libs. If it was flexibile enough it might even be used for "authoring".

Audio might include just a voice describing the kind of sound effects to be applied at given times, as description of how a voice should sound, el cheapo effects, etc.

Subtitle text could be used for comments by producer, lighting and sound techs, 3D effects team, script writers, the script (options).

The quality of the material used for drafting might be improved over the course of the project. Sketches could be replaced by rehearsals, or script reads, preliminary storyboards from 3D effects workers, etc.

This allows also for the pre-or concurrent consideration of the general flow of the storyline, and helps to show what scenes need more work to be done on them. Maintain an even level of presentation (work within bounds of time and resources to achieve "perfection", while avoiding the chance that some scenes will be obviously below par.

Every person involved would be able to "see" and "watch" the part where their work is going to go. This has hidden effects (probably positive) on team workers as it adds to the assurance that what they are working on is less likely to get "cut" out. And it also helps production decisions, to make cuts of scenes, before the really big bucks (or laborious hours) have been allocated/spent.

To provide features for this kind of approach does not require many new functions in terms of "what gets done" with/to the audio, video and pictorial content ; it is more about "how it gets done" and how soon ("when").  This approach could be done with just about any multitrack editor, but the question is - "How easily?" .

It is a matter of managing the resources, and how they can easily be replaced by newer versions, or optional takes/scenarios.

Transcriber http://trans.sourceforge.net/en/presentation.php

Found this example of this kind of program function (Sat 12 July 2008) "CeltX"      http://www.celtx.com/overview.html

http://celtx.com/images/screenShots/storyboard640.png

. --["Tree"][[DateTime(2008-05-26T10:15:00NZ)]] .

== Associate Music with Clips ==
Sound tracks can be chosen for video, after the composition has been done. But it is helpful to have assistance in suggesting what music is suitable - either for the entire video or for during a particular clip. "Genres" could be assigned to videos, just like they are assigned to music. So this allows the genre of the video (or clip) to be matched with music genres, to shorten a search list for suitable music tracks.

Other characteristics of the video could be used to select music. Parameters such as suitable beat tempos (slow, fast, some irregularity, hoppy/skippy, etc), topic/subject, activities the song may mention.

This can work the other way as well. Not just finding music to match a video, but can also be presented with some music, and get the video archives to call up some good choices for video to match the song. (e.g. promo infomercial for a new range of rock n roll cds - need some reminiscent footage to match the songs).

. --["Tree"][[DateTime(2008-09-26T14:57:00NZ)]] .

----

== Loop Play Preview "while" editing ==
Able to set a loop play that spans the area being edited, so that it will constantly play the strip, with the live updates of the recent edits made.

In the case where an automated workflow system may have composed a draft layup(s) then it could loop through the draft layup(s) in order.

 . --["Tree"][[DateTime(2008-08-23T23:51:00NZ)]] .
----
= fast Render and Play capacity =
== User adjustable resolution of thumbnails in video tracks ==
For situations of '''live rendering''' on the tracks and to save time, and processor, the video quality displayed in the track, and / or the composer (or other viewer) could be set to lower resolution, or rougher calculation. This allows for speedy general comparison of factors like positioning, general brightness, timing of events, effects. So this would speed up the initial stages of numerous iterations in design. Leaving more time (and energy and patients) for the final stages where good visual resolution is needed). The images as displayed could even appear quite "blocky" or "blurred", but you won't have to watch in slow motion, or wait ages for a render. So by the stage you get to committing to lengthy renders, you are already fairly confident that a good portion of it is going to be close to what you are looking for.

 . --["Tree"][[DateTime(2008-05-07T18:49:00NZ)]] .
== Render fast draft mode does every "x"th frame only ==
During draft mode, the render effects can be analysed after a quick render by only rendering a proportion of the number of frames. Just enough frames to make sure the quality is good enough, or that there are no gross problems. So by the stage the user comes to do a full render, they are already confident that most of it will be at least roughly OK.

Methods to speed up draft rendering, reduce the amount of time spent iterating the initial project. More rapidly approaching what is wanted for the general concept and preliminary final draft - to check that visual appearance is acceptable (or excellent). Only when at the Final stages, does much time (Mips) get devoted to rendering.

 . --["Tree"][[DateTime(2008-05-09T14:20:00NZ)]] .
== Render fast draft mode does every "x"th frame only Playback method ==
Rendering that has been done on only every "x"th frame, can be played back at normal speed, by slowing the rate of picture display (saves file size by the ratio of frames not needed), or by multiple copies of the same picture being saved in the file (takes up the same space as ordinary render, just saves time).

So the rendered track can be used for further draft work, and only near the final stages does the video content of the track need to be changed to the full frame high resolution version (which its self may be an update of the changed video that it is created from).

 . --["Tree"][[DateTime(2008-05-09T14:20:00NZ)]] .
== Fast Edit Mode (on Low resolution video) and workflow Script Generator and Manager ==
see http://pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverviewThe work that needs to be done on the project, at least to draft stage could be made faster by  '''''using lower resolution video file formats'''''. These allow most of the edits to be "timed" and mostly adjusted to levels. Check runs can be done quickly. Only when the work is near completion does the actual high resolution raw video need to be used. If the "undo" feature is used to generate script (preferably with the errors removed), then the project can be carried out on the good video.

On the architecture diagram this would be represented by an arrow from the GUI to the script box.

The whole process is like using a wordprocessor - use recycled and waste paper for drafts, put in the good media (paper) for final.

The scripts could be edited just like macros in a wordprocessor. Routines could be created, or extracted from the script, and saved. Some settings could be left for user adjustment live, or before running the script, or as a default.

 . --["Tree"][[DateTime(2008-05-16T19:24:00NZ)]] .
== Fast Download and Play using Low resolution compressed video - for viewing latest draft version of the project. ==
It might be useful to have the ability to generate draft versions of a video project, in lower resolution and compressed format. These would allow directors/editors/whoever(authorised) to download copies fast, and view the remotely. This cuts down on bandwidth and wait time. The drafts may be generate manually, be scheduled, or be triggered by the completion of some stages. The drafts may be of the complete project, or by scenes, etc. Each separate team on a large project could generate their latest draft, which don't need to be synchronised. When somebody requests a view of the latest drafts (some may be not so recent), then all the "latest" versions get collected, and a playlist is generated, and sent to the requester. This makes it easy to check the latest status. . --["Tree"][[DateTime(2008-09-06T21:33:00NZ)]] .

----
= Effects =
== LADSPA Audio Effects Manager ==
Cinelerra can use Ladspa audio effects plugins, so Lumiera probably will be able to also. The ability to add Ladspa plugins to Lumiera, OR to point it to where Ladspa plugins are already loaded could be improved upon Cinelerra. Improvements might include ;

 * Easy means to "browse" or "find" other Ladspa plugins on the system (or network).
 * Easy means to download and install plugins into Lumiera (which may also make them available tot eh system and other programs).
 * Easy one-stop-shop appraoch to finding additional plugins on the net. Users and plugin writers can submit new sites/sources to Lumiera, and the list of links can be downloaded from Lumiera. The list might include standard recommendations on reliability, ease of use, and functional application.
This would cut down the time spent searching for new plugins and experimenting with them. It would encourage plugin writers because they can get a quick user base rolled out by submitting to the list. . --["Tree"][[DateTime(2008-06-04T19:03:00NZ)]] .

== LV2 successor to LADSPA Audio Effects Manager ==
http://lv2plug.in/

LV2 is a simple but extensible successor of [http://www.ladspa.org/ LADSPA], intended to address the limitations of LADSPA       which many applications have outgrown.

. --["Tree"][[DateTime(2008-09-06T21:54:00NZ)]] .

== Gmerlin and Gavl video effects plugin ==
http://gmerlin.sourceforge.net/plugins.html#plugin_fv

. --["Tree"][[DateTime(2008-09-06T21:57:00NZ)]] .

== Cross Media Effects ==
Cross Media Effects where the sound effects the picture, or the picture effects the sound. Such as brightness effects Volume, Volume effects Brightness, tone effects hue or relative brightness between colours. Colour histogram effects sound spectrum. Don't record picture for low sound intensities, don't record sound while picture looks like "this".

 . --["Tree"][[DateTime(2008-05-07T21:34:00NZ)]] .
== Sort or select or access effects based on their "transparency" requirements ==
Have a means to view/sort/limit use to effects that do/don't need transparency colour models. Or, have a way to be told that the effect needs a transparency colour model (user option to choose whether you want this warning).

This is helpful for people that do not have high powered PCs, or would like to keep things simple so they can work fast.

 . --["Tree"][[DateTime(2008-05-14T09:49:00NZ)]] .
== Speech to Text effect and database search function ==
A plugin for speech to text detection could be made. This would allow the automatic (live or post-record) transcription of the dialog. The text of the transcription, can be used for subtitles, keyword identification for cataloging, and searching the general text. The space taken up by the text would be small compared to the space taken by the video. This cross media function means that it would be possibly to search for keywords, or words in proximity to each other,or phrases, and the search could be done across an entire library of clips, and then search (or have on record) for where on the listed media the search results appear - then make then available for viewing, putting on DVD, or laying up in multitrack view ready for trimming. Imagine the increase in usefulness of old news articles and documentaries. This could even be applied live in interview situations where it might be useful to go back and find what somebody just said.

. --["Tree"][[DateTime(2008-09-12T19:55:00NZ)]] .

== Search for clips with similar sound tracks, and lay tracks up with sound as first guess synchronization ==
This would help find all the clips related to a shoot/event based on the sound content. It would also help to synchronize/align the tracks based on the sound track. The sound may be out by a few seconds (or less), but it would be very helpful in the initial layup. There is a simple OS utility to find duplicate sound files called, fdmf. The code in this might be useful for creating the above feature.

http://www.w140.com/audio/

It could also be used to automatically categorize clips, according to their sound content, by comparing with sampled sounds (e.g. loud noises, water/waves, traffic, singing, birds, drums, thunder, etc) . --["Tree"][[DateTime(2008-10-13T18:45:00NZ)]] .

----
= Motion Tracker Effect =
== Motion Tracker - Full Independent and Multiple Axes ControlsTheControls ==
The motion tracker effect currently has one box which detects both horizontal and vertical motion, another box for rotation, and both of them are forced to share the same centre coordinates, for one point. Much more motion would be more accurately detectable, if more points could be chosen, and optionally restrict them to any combination (or sole purpose) of x,y, rotation. Each with the area of motion boxes. This would significantly reduce the chances of the motion tracker getting totally lost, and would improve the correlations, particularly on jittery tracks.

 . --["Tree"][[DateTime(2008-05-07T18:49:00NZ)]] .
== Motion Tracker - Record/Detect and Play/Use/Apply mode settings for Tracker GUI - intuitive approach for user ease ==
1) The Motion Tracker GUI is not as intuitive as it could be.

In summary, there are two main actions ; (1) get the motion data, (2) use or apply, the motion data. A third action might be "check" the gotten data (which could possibly include the ability to manually edit the data by number entry boxes, and spline fitting interpolation curves)

The motion tracker user interface would be much easier to learn to use, if the settings were clearly distinguished/separated into "Get/Detect" mode, and "Use/Apply" mode. The need to reset calculation, action, draw vectors every time that you change from "Get" to "Use" is very laborious if you are "checking" and (try, try) trying again. To be able to set how you want to have each of those settings for when you "Get" and when you "Use", means that you can then just toggle (one click!!!) between "Get" and "Use" mode - easy peasy??

The settings that use "settling speed" could be visually indentifiable as being associated with s.speed (say a box around them all) or at least near each other.

So the window could be compartmentalised into two sections ; "settings for Getting motion data" ,  and "settings for Applying motion data".

2) For improved clarity for the user -

The "Tracking" functions could be grouped together. They are described by "How they work" not "What their objective is" ("What" they are useful for). The user does not need to be confused with "how" a task is done technically (though it is a good debugging reminder). The user is guide by "what" they want to do. e.g. they want to "save" a file - they use the "save" button in the "file" menu - not the "write" button in a "hard disk management" menu.

So either a label that means more for the user's task objectives, or an explanation near the label would be very helpful (help pop-up, "?" enabled, or just text in the panel).

Using the approach of "building Out" technical issues to make user tasks work faster. The advantage of disabling "play" while making settings, and then re-enabling it before a pass, is laborious (again). Remember to move mouse to play icon, click, move back, and remember to do the same after making settings (OR blast - I forgot [again]). Just disable the rack that is be worked with automatically as soon as the motion panel gets activated. And Reset it automatically when the pass is initiated.

 . -- ["Tree"][[DateTime(2008-05-23T17:08:00NZ)]]
== Motion Tracker - "Get"/"Apply" - user method ==
Currently the user needs to work with three windows visible (Trackview/timeline, Composer, Motion Tracker window). But once the user has selected the region in the Trackview that the effect applies to, the only reason why they need to return to it (other than watch it - if they want to), is to press the play button, and toggle the "play icon". This involves mouse motions and clicks, and can also involve whole window manipulations just to get there.

If the "play icon" is automatically toggled (or can be toggled from inside the motion tracker window), then if the "Pass" for "Get" and the "Pass" for "Check ViewApply/Use" mode is able to be triggered from the track motion window, then a large amount of driving the mouse around is removed.

The "Get" mode, and the "Use/Apply" can be made to "Pass"(play) directly from the motion tracker window, say by clicking on a "Get" button, "Check View" button, and an "Apply" button.

 . --["Tree"][[DateTime(2008-05-23T17:36:00NZ)]] .
== Motion Tracker - manipulations and combinations functions ==
Aswell as motion editing features (for tweaking the curves) , it would be handy to carry out other operations on the motion data.

For example, an object that is moving relative to another object which itself is moving relative to the scene. The camera may be mounted on the second moving object. The background scene needs to be stablised say for rotation and vertical motion (boat pitch and roll), and the first object can then be tracked in sideways translation (which will be rolling, but the picture does not follow the roll) (say stuff sliding on the deck, or something hanging). This would involve the combining of two motion sets, or sets from two tracks.

Also an object might move, but does not need to be kept in the same location of the camera view, and may be allowed to drift from side to side (up or down, "position" wise - not dependent on "time" lags). So the compensation used is not "equal" to the motion, but is a proportion/fraction of the motion. In another case, the object motion may be desired to be over emphasised by making the camera appear to "over anticipate" where the "subject" is moving to, so the applied motion will be more than, or a multiple of the detected motion.

The above examples are situations where an "operation" is carried out on the "Detected" motion which is being  "added"/"subtracted"/"divided"/"multiplied" by an "amount" or another "Detected" motion to arrive the the resulting motion to be  "Applied". Another "operation" that could be applied to the motion data, is to correct it for the change in Zoom from camera to projector view.

This means that the motion data set obtained for the track, can be applied to other tracks that have some form of "interplay" with it. One example is using duplicate tracks for sources of different parts of the frame, to be used as inserts in the final picture. They all need the same compensation, but as they get enlarged or reduced, the user may want to edit/alter the relative amount they get moved.

 . --["Tree"][[DateTime(2008-05-23T18:54:00NZ)]] .
== Motion Tracker - scalar values of motion vectors shown as level in tracker view ==
The "camera" and "projector" X,Y and Zoom values are shown in the Tracker View on the time line. Just like this, the Tracker values for X,Y translation and Angle of rotation can be shown for "detected" motion, and "applied" motion. They could be similarly edited on the Tracker view.

 . --["Tree"][[DateTime(2008-05-23T19:04:00NZ)]] .
== Motion Tracker - colour matching of motion in composer, tracker, and motion control knobs ==
The motion tracker boxes and vectors are not colour code (or line styled) to help distinguish between each of them Colour coding could be applied to the composer view boxes and vectors, the corresponding knob adjustments in the motion vector control, and vector levels (which could be) displayed in tracker view.

 . --["Tree"][[DateTime(2008-05-24T16:55:00NZ)]] .
 .
== Motion Tracker - Concept for improved features and GUI ==
The following image is an example of how the panel)s) for the motion tracker could be improved. Note the tabs for workflow left to right. Note the order of decisions from top to bottom. 3 axis separation, reduced confusion as to what setting to use for what purpose.

attachment:motion_tracker-tree_version_03.jpg

 . --["Tree"][[DateTime(2008-05-25T23:32:00NZ)]] .
== Motion Tracker - alternative to manual use of "Blur" and "Histogram" effects to improve result ==
Currently the smoothness and accuracy, even just the success, of motion tracking is helped by the application of "Blur" and "Histogram" effects to the track. This is a repeated and many step task. It could be made easier, just by having an option from "within" the motion tracker window to select "Blur" and select "Histogram". But these names do not suggest to the user "why" they should consider the choice - a more meaningful choice would be to choose "more general SHAPE" (mostly effected by blur) and "more general COLOUR and CONTRAST" (mostly effected by histogram).

The blur and histogram effects used by motion tracker can be applied to a temporary duplicate that gets made of the selected track, so they are not causing interference with the other effects that the user actually does want.

The amount of blur and histogram to be applied cane be adjusted with an additional control within the motion tracker window. An indication on the estimated increase in proportional calculation time could be made, in a numerical display box below it.

The blur and histogram algorithms are forms of averaging out the importance of a pixel relative to its neighbouring pixels (1,2,3, or more pixels away). There might be some room for adapting the algorithms to be better tuned to the use of motion tracking. Very little extra coding needed, just using the code in a slightly different way.

 . --["Tree"][[DateTime(2008-05-26T11:25:00NZ)]] .
== Motion Tracker - Resources ==
The motion tracker effect has been tackled in some other projects also.

 * Voodoo was one project carried out by DigiLab at the University of Hannover. The project will soon have a web site set up for it's spin-off company at http://www.voolution.com/ (not functional at time of writing - but bookmark it for developments). The person in charge is Kai Cordes http://www.tnt.uni-hannover.de/~cordes/ , and Hellward Broszio who used to work at the University http://www.tnt.uni-hannover.de/staff/broszio/ and now is associated with the spin-off company. Voodoo (pre-spin-off version) for linux and windows is available for educational use from http://www.digilab.uni-hannover.de/download.html . Tutorials can be found at http://video.aol.com/video-detail/voodoo-camera-motion-tracker-with-blender/1160794060 , http://www.leechvideo.com/key/voodoo-tracking-blender/ . Voodoo works with Blender.
 * Icarus is available for educational use only from Peerless Productions, with tutorials available.  http://www.peerlessproductions.com/tuts/pages/Icarus.html and more tutorials at http://www.peerlessproductions.com/tuts.html and http://www.hethfilms.de/films/tutorials/3d_motion_tracking/  . Icarus was bought by PixelFarm who also have a number of commercial products available http://www.thepixelfarm.co.uk/products/category.aspx?Cart=1&catID=1
 * Oculux is a Video Analysis Software with automatic point recognition intended primarily for Sport Analysis in 2D. It is aGNU open source project for windows but is being written in C# so the code might be easily transferred into Lumiera, and is in the planning stage, so they may be open to flexible project plans (re accommodating Lumiera). http://sourceforge.net/projects/oculux/#item3rd-1
 * Frontera is an open art project which uses interactive video combined with  '''''hand tracking'''''''''''''''''''''''''''''  to make an "interactive portrait". It uses  '''''open standards'''''''''''''''''''''''''''''  like  '''''Opencv '''''''''''''''''''''''''''''and the '''''OSC protocol'''''  , written in C++. The hand Tracking code could be adapted for use in Lumiera. The project is at a very early stage. http://sourceforge.net/projects/frontera/
 * A "Universal" port of the open source "Crimson FX" program to Tiger. Crimson UFX can be used to add '''''lightsaber effects (motion tracking)''''' to videos. Beta for MacOS X written in C. http://sourceforge.net/projects/crimsonufx/
These are options for motion tracking systems. There is the (remote ?) possibility that some sort of deal can be done to share the code, and development tasks, to make either of these packages available for the Lumiera User's Community. Voolution and Digilab are interested in user feedback which is helpful for their development cycle. It might be handy anyway to maintain compatibilty with these and similar projects/products for users' choice.

. --["Tree"][[DateTime(2008-05-20T17:08:00NZ)]] .

== Camera Tracker - Full Independent and Multiple Axes Controls ==
Similar to the motion tracker function, but is applied to points/objects/items/features that remain fixed in space. The camera horizontal angle, vertical angle, rotation of view, and zoom, can all be extracted. This can then be applied to the track to maintain constant stable view point of the camera (even though the camera may have been moving around , and zooming a bit)

 . --["Tree"][[DateTime(2008-05-09T17:02:00NZ)]] .
== Camera Tracker - Auto tilt and pan when zooming, to keep object in same frame position ==
When zooming in or out, it is often desirable to keep a certain object or feature in a fixed location on the screen. For example head in the middle or top of view, feet always at the bottom, window to the right edge. The object tracking functions in the motion tacker could be applied to automatically adjust the pane and tilt to keep an object in the desired location of the picture, when the zoom is adjusted. This would reduce the need to manually make compensation to bring the object into frame, or place it. The only manual input required would be to do a touch up near final editing.

So by choosing an object or its respective side, and dictating its location in the screen, the only adjustment that needs to be made is the zoom. This reduces to a half or even a third, the amount of playing around with the level controls, in order to get an acceptable "frame up'' during and after zooms. ''

 . --["Tree"][[DateTime(2008-05-29T12:43:00NZ)]] .
== Importance of Motion Tracker ==
The motion tracker is handy for removing spurious camera motion, that the camera has not removed, and is very good for stabilizing video that has been digitally zoomed in on in Cinelerra (Lumiera).

. --["Tree"][[DateTime(2008-09-09T09:17:00NZ)]].

== Motion Tracker and auto mask detect Effect ==
This is a combination of the motion tracker, which can track an object in view, as well as an object detection effect. The object detection effect, detects the object, looks at its motion and movement the object's extremities, and decides on suitable crops or masks that are time averaged and motion compensated to give a smooth flow. This is useful for automatic zoom and selected insert material.

The effect removes much tedious work from the person doing the editing.

An improved method to implement this might be; Various first guesses made as rough thumbnail tracks could be made and the user chooses some of the tracks they prefer. The user maybe is prompted for some preferences for fine adjustments such as "zoomin/out a bit", allow faster motions of the tracker (pan/tilt bit faster).

. --["Tree"][[DateTime(2008-09-15T17:51:00NZ)]].

----
= Firewire =
== Firewire IEEE1394 concurrent device input ==
Provide features for timing, scheduling, relative levels, colour matching etc, for multiple concurrent firewire video and audio, and other analog captured live recordings.

 . --["Tree"][[DateTime(2008-05-07T21:35:00NZ)]] .
== Sound Capture from Fire wire Audio Devices ==
Cameras are not the only firewire devices. There are sound capture device and even 12, 16,18,24 track mixers that will output each track as an independent ieee1394 track. Cinelerra and Lumiera could well be able to cope with these. What a great mix for your production?! Having more editing functions for audio would enable all the mixing desk functions  to be available.  So as well as gain, there can be High, Mid and Low tone controls, equaliser, all the sound plugin technologies, routing to external programs *(though I am not sure if that would maintain the tight timing as per within DV in Cinlerra/Lumiera.

The FFADO project aims to provide a generic, open-source solution for the support of FireWire (ie. ieee1394, DV-audio) based audio devices for the Linux platform. It is the successor of the FreeBoB project.

The code is beta, so it may be too soon to add it for most people. But it is something to look out for.

[http://ffado.org/ http://ffado.org/ ]

http://freebob.sourceforge.net/index.php/Main_Page

[http://freebob.sourceforge.net/index.php/FreeBoB_on_Debian_GNU/Linux http://freebob.sourceforge.net/index.php/FreeBoB_on_Debian_GNU/Linux ]

 . --["Tree"][[DateTime(2008-05-07T21:35:00NZ)]] .
== Firewire IEEE1394 Management ==
Firewire routing manager (like jack video). Also control Output to firewire hardisk,or other channel which may be being used as input by another program.

 . --["Tree"][[DateTime(2008-05-12T17:04:00NZ)]] .
== Firewire Camera Management ==
Firewire cameras can have some of their settings controlled via firewire. There could be a toolbar in the viewer for a camera's track to control the camera.

Really handy to send the camera a white balance command, or control exposure/focus/mode etc.

There may even be some diagnostic features in firewire to keep your camera in  good working order.

 . --["Tree"][[DateTime(2008-05-16T17:42:00NZ)]] .
== Firewire IEEE1394 Command Recorder ==
The commands that get sent ti the camera(s) over the firewire network, could be recorded. Zoom recordings would be handy in particular so that the "zoom" setting for the camera at the time the footage was taken would be known. So using an effect similar to "motion tracker", lumiera would be able to figure out the amount of zoom to compensate for the zoom used when taking the footage so that the footage can be "automatically" processed to look like it was at a constant zoom.

Another application would be to apply the zoom recordings from one camera, to the track of another camera so they both get mixed with the same zoom in ratios. The camera track that is having the zoom superimposed on, may have first been adjusted to take away its own zoom effect - or - it's own zoom gets subtracted from the desired zoom, to calculate the correction.

 . --["Tree"][[DateTime(2008-05-24T16:31:00NZ)]] .
== A note on Firewire IEEE1394 capture and network for concurrent device capture. ==
After 6 to 8 hours of continuous recording from  '''''consumer grade camera via ''''''''firewire'''''''' port using Kino (no frames dropped)''''', the sound does not vary its shift relative to the picture. Any offset at the end is the same as the offset at the start (e.g. distance from camera mic to speakers down at a stage, or latency in analog sound system between stage mic and speakers or mixing desk output. When this offset is adjusted at one point, it applies to the whole (unbroken) strip.

The firewire network system has built in synchronization, so a frame from every camera (up to about 64 cams) is collected at the frame rate (e.g. Pal 25 fps). The sound comes through the camera and is kept in synch. Even a firewire audio mixer (say 2,4,8,16,24 independent channels) is kept in synch.

For reason of constant offset (if any), firewire is very desirable for capture. Just lay up All the video and audio tracks, move them so they coincide (see suggestions for time shifting, markers and labels). If more cameras are needed, at once, then the system can do it. You can record to different hard drives, but just use the firewire network to keep everything in synch for when you bring all the files together.

Most consumer gear will only work for the lower speed firewire (a and may b) which can only go short distances. But firewire switches (more frequently) have the ability to do  '''''firewire c which can go much longer distances'''''. So if you want to synch cameras live over long distances then you can feed the camera into a switch, down the long cable, into another switch, and then to the PC (or other firewire gear). The switches usually have speed adaption on "each" port that will figure out what speed the port can go at for max performance. That means that consumer cameras can effectively send over (faster) c grade distances, by using the switches.

There are systems that allow ethernet to be sent over firewire, so it is possible to run an in-house network over the same cabling. This is just what you need if you want to remotely control such things as camera mounts, lighting, remote PCs and hard drives, voice communications with people (sound man, camera operators, directors, etc)(see note *1* below).

There is also the possibility of running firewire over an ethernet, but the synch may (am uncertain) have a small amount of "float" in the synch, but it would be kept within a fine tolerance. And ethernet can go far and afar.

note *1*    __Control of external Devices__

All the controls for these remote devices and communications need to be managed. This can be done separately from Lumiera, but could also be blended in some way(s). But they would at least have to co-exist on the desktop in some situations. Just as a live camera crew might use pre-programmed transitions and effects when doing (say) a live newscast of a sports event, so the lighting and camera mounts could be triggered to carry out "recited actions" by an action made in Lumiera (rather than having to get two people to try and press some (software) button at the same time.

So even having a function to send a (trigger, hold, or toggle, or even data) signal to output ports on a PC as a result of certain actions in Lumiera, might be handy. On the smaller scale this could be useful for controlling analog cameras and video players (maybe even using adapted remote controllers connected to printer or serial ports). Signals could be emulated for other hardware (remote) controllers (e.g. such as analog video switchers). The sound card could be used to emulated analog control signals that are not possible by using the printer or serial ports). This is not even considering the possibilities of data communication with as yet undesigned micro-controller devices.

. --["Tree"][[DateTime(2008-09-05T16:11:00NZ)]] .

== Firewire Camera Capture and Video Streaming using GStreamer and/or PureData - remote video capture trunk ==
There are some python scripts put out by GISS.TV .

1) DVStream.py can stream video captured from a DV Camera and stream it using GStreamer. http://giss.tv/sahabuntu/doc/gstreamer-dv.html [http://giss.tv/wiki/index.php/Sa'habuntu_Live_CD http://giss.tv/wiki/index.php/Sa%27habuntu_Live_CD] http://giss.tv/wiki/images/f/fd/Dvstream.pys

2) giss-pdp-dv.pd can stream video captured from a DV Camera and stream it using PureData. http://ydegoyon.free.fr/giss-pdp-dv.pd http://giss.tv/wiki/index.php/Streaming_Tools [http://giss.tv/wiki/index.php/Sa'habuntu_Live_CD http://giss.tv/wiki/index.php/Sa%27habuntu_Live_CD]

These programs could be useful if the user wants to collect video from distant sources. All it would need is a plugin to accept an incoming stream, and it could be recorded, or live mixed, with local, or other distant sources. It may also be possible to have a plugin that uses these programs to stream from Lumiera, either live, or draft form.

. --["Tree"][[DateTime(2008-09-06T21:19:00NZ)]] .

== DVgrab and Kino example of possibility to capture, stream and pre-view at once. ==
The possibility of capturing DV, while streaming and pre-viewing is discussed at the Kino website.

 . http://www.kinodv.org/dcforum/dcforum?az=show_topic&forum=101&topic_id=3233&mesg_id=3233&page=
The concept is to use dvgrab's ability to output to pipe while capturing. Preview might be possible if you can tee to a named pipe and use something like ffplay or vlc to view it. Then, continue the pipe to like ffmpeg2theora for streaming. Even if this system is not considered ideal, the components could still be useful for implementing the features Now, and help ensure the interface to the main engine works well, so that what ever may be used in future is able to be confidently connected to the interface. And who knows, it may work well as it is.

. --["Tree"][[DateTime(2008-09-13T11:15:00NZ)]] .

== ffmpeg has DV capture feature that could be used as ieee1394 firewire Camera input ==
ffmpeg dv video capture commands and setting for firewire input see;

http://doc.gnu-darwin.org/ffmpeg/ffmpeg-doc.html#SEC11
http://www.ffmpeg.org/ffmpeg-doc.html#SEC14


and also for video4linux devices see;

http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html#SEC3

as well as screen grabs (great for tutorials, and debugging feedback) see;

http://www.ffmpeg.org/ffmpeg-doc.html#SEC4

. --["Tree"][[DateTime(2009-01-31T11:00:00NZ)]] .

== Hornets Eye ==
Video processing and computer vision library for GNU/Linux offering interfaces to do image- and video-I/O with  '''''ImageMagick/Magick'''''''''''''''''''''''''''''++, Xine,  '''''firewire''''''''''''''''''''''''''''' digital camera ('''''DC1394'''''''''''''''''''''''''''''), and video for linux ('''''V4L''''').

http://sourceforge.net/projects/hornetseye/#item3rd-2

. --["Tree"][[DateTime(2008-09-08T11:02:00NZ)]] .

== Firewire IEEE1394 as a multicasting network ==
Firewire places the data from each firewire input device into a "channel" timeslot on net wetwork. Any device can receive the data from the input device, just by listening to the "channel"'s timeslot. No further bandwidth is required of the input device or the network. So firewire is handy way to distribute video (and sound), as well as collect it.

Output from programs could be feed to a firewire network (more than one network could be used), for distribution say to a live onsite screen, other processors, any program/PC that can encode the data into various formats, and streaming servers.

 . --["Tree"][[DateTime(2008-09-09T10:58:00NZ)]] .
----
= Live Video Mode =
== Live Mix Mode - "reverse polish clicks" ==
Video could be mixed live to an output file and/or stream. Similar to a radio station, there can be resources of clips to insert and overlays. Transitions can be effected fast by clicking on the transition mode which begins with the main signal as default (otherwise click the actual stream to be "changed from"), then click on the stream to be "changed to". any parameters of the transition could be made before it is called. The transition could be scheduled in line waiting to be manually triggered. Or it could be triggered by the time,or visually or audio event, or remote control (from assigned key).

There could be an option to record the output stream locally. Also an option to record the relevant tracks for "x" seconds before and after a transition call, so that post editing is possible to make a final copy with less chance of error. This approach saves having to record all tracks for all the time,  which also prevents them from being mixed till only after the whole shoot has finished (which can take up a lot of hard disk space). The right hand side of the track timeline could show a condensed view of the order of the scheduled transitions. The time time would release them for moving to the left as their time for use advances. The transitions might be represented on the timeline as a vertical bar wide enough to show a picture of the size of the inset (on the line of the track used for the inset), the size of other tracks on the screen, and a very rough indication (appearance or icon) of other effects that get applied. ''' '''''''''  '' ''

'''Catch events from many angles - action replay'''

 . There could be a facility to keep a copy of each track (or groups of selected tracks) for "y" number of seconds/minutes after which it gets Dumped. But there could also be an option to begin Saving the last "y" seconds and what follows for "replay" or covering a significant event.
 . . '''--["Tree"]'''[[DateTime(2008-05-07T20:20:00NZ)]]''''' .'''''
== Live Mix Mode view tab - showing transition too bar, and queue of transition sequence. ==
 * The left end of the track shows the camera captures for the input channels and the projector view for the output channels.
 * The next transition (T07) which is about to be done (or Is being done), is shown on the left side of the track view.
 * The track view shows a series of thumbnails.
 * The timespan of the displayed thumbnails is a little bit more than the buffer time (for replay purposes).
 * The sequence of next transitions can queued up on the right end of the track view.
 * The transitions can be composed, viewed and edited (e.g. T08).
 * The transitions could also be selected from a set of defaults, or pre-arranged custom transitions (sets).
 * The transition selector could be displayed in a tab to the right of the queued transitions.
 * The tabs strips (vertical) show an iconic representation of the effects, settings and processes used to make the transition.
 * (note In the example the colored squares represent the icons.)
 * These icons serve as a visual prompt as to what is going on with the transition, and helps by not needing log descriptive textual names.
A textual name for the transition could be vertically read from bottom to top (sideways), and be placed on the right side of each tab. This would allow a standard set of transitions for re-use in similar projects, and naming would make it easy to chooses the transitions in the order needed.

Not shown in the example;

In the tab label or near the top of the tab strip, there could be some icons for easy access to tasks such as ;

 1. dump this transition from the queue.
 1. execute this transition NOW
 1. move this transition up the queue.
 1. move this transition down the queue
 1. open this transition for viewing and editing The tools, look and feel is in keeping with the rest of the program, and is very similar to the node designer, and usual transition & effects editor.
attachment:Screenshot-Cinelerra_live-capture-view-tree-01.jpg

''--["Tree"][[DateTime(2008-09-03T12:58:00NZ)]] .''

== Why might Lumiera be so important as a live video system? ==
If Lumiera can capture live, maybe from several cameras, and/or video stream sources, and if it can live mix and do transitions and effects, then it can generate product fast. if it can stream it or have it ready for upload/download (depending on who is in control) then it is even more attractive.

If it can be used to make fast good looking edits on recently captured content, then it can be used to create "ready for air" content on site, or in the studio, with hardly any significant time delay. This applies to situations where content includes recent/current events, but content is not live and benefits from clipping, and sprucing up. But it could also be used in live situations, where replays may be needed, or fill-ins of high relevance to the on-site activity are needed.

There is an additional benefit of being able to use the editor as the live program editor, because

 * all the tools that have been laboriously and carefully developed in the studio, are available for immediate use in mixing and transitions in the field.
 * the users are more likely to be familiar with the same GUI, and tools.
 * the same program can be used across the board, so compatibility is 100%
 * if the workflow system in the program is used, then it can be tuned to either studio or site use, just as easily.
 * the PCs/laptops that have Lumiera on them, provide much greater rates utilization and flexibility, portability, and system redundancy (more likely to have a replacement on-hand)
 * with streaming or download capacity, then program content can be delivered fast enough for live broadcast.
It might not be considered an urgent priority at present, but could be well worth keeping in mind as a future possibility. --["Tree"][[DateTime(2008-09-06T22:15:00NZ)]]

----
== Piping Output to Streamers ==
The output could be piped to streamers, either to files, or to stdout. VLC may be handy to interface to, but there are many others.

See '''Theorur ogg icecast streamer''''''''' at http://sarava.org/theorur/   and '' ''

a how to at http://mcs.hackitectura.net/tiki-index.php?page=live+stream+ogg+theora+ffmpeg2theora+oggfwd '' ''

Theorur streamer is a GUI frontend for some command programs to stream. It '''''takes video from FireWire ieee1394 and V4L'''''''''. ''

''The gui could be triggered from lumiera, or run within a panel window, or be kept externally, but considered as part of the "kit" of Tools. ''

 . ''--["Tree"][[DateTime(2008-05-07T20:38:00NZ)]] . ''
== Disable Routines and un-needed resources during live streaming ==
To keep reserve processor capacity and disk access, un-necessary parts of the program (which the user could have options to choose) could be disabled.

 . --["Tree"][[DateTime(2008-05-07T21:34:00NZ)]] .
== Reliability of stream starts at Lumiera ==
The configuration files of the streamers used could be backed up from within Lumiera (let it know where the original files are), so that if the programs get changed by external use, they can still be called up from Lumiera and run as per requirements.

 . --["Tree"][[DateTime(2008-05-07T21:34:00NZ)]] .
 .
----
== Adding Fonts ==
Easy Fonts add and management. But also show the fonts manager where the normal system fonts are, and just let it know which ones it can use. Or import from system, or other software fonts folder

 . --["Tree"][[DateTime(2008-05-07T21:34:00NZ)]] .
----
= Proposals from a FCP user =
== Effects/filters and masks/alpha channels ==
 * Effects can be limited by a mask/alpha channel. This can be achieved by nodes based effects. (In FCP I need to duplicate a layer and apply a mask and filter to the image)
 * parameters of a filter can be set by an additional alpha channel/mask per pixel. (for example the amount of gaussian blur)
== Data analysis for motion stabilisation and more ==
my view: Video analysis is an area that is just starting and will be much more important in a couple of years time. There are many applications that can use image analysis data, even more than we can think of now. Some of these are identifying objects to quickly apply a color correction on an object, or to apply a smart background blur that simulates camera focus blur, or to make smart auto-color corrections and so on and so on. The quality and purposes of this will grow over time, but it is good to have this logically embedded in the workflow. Data analysis starts in the camera, for now only focus distance. Once imported more analysis can be applied in a way that many filters can use this. The first filters/effects to use this will probably be: motion stabilisation, image tracking and fluent slow motions.

== Tiling ==
*sounds nice, I can imagine having unequally sized tiles. For example bottom right the image with filters (400x300pixels), top right a waveform monitor (400x75 pix), top left the image without filters(100x75 pix) and bottom left perhaps a vectorscope or clip info(100x300 pix).

----
= Work Flow Manager - project management FOSS plugin =
To Do list Percentage completed Expected time needed. expected completion time. what it depends on. Completed

Assign tasks on the '''''track timeline'''''. Whether they are touching up the picture. Effects. transitions. Awaiting further material.

user can select to display on the track time line the portions that are ;

 . -completed -being drafted -yet to start -worked on by who
Easy way to split up the tasks on a video. Quick way to find the most important parts to work on. Improve estimates of time to do work on something.

Can '''''use any open source project management program as a plugin'''''''''''''''''''''''''''''. '''''Project management program''''' would show how the project moves from concept stage, through to filming, through to drafting, through effects, titling, subtitling, and final runs. Improves not just product, but methods of making product. Not urgent for Lumiera, but certainly makes it very attractive for a "total operation" approach.

Estimate costs of each scene - props, costumes, actors, staff, vehicles, etc. Scheduling of time, equipment, resources, etc.

Check timing of events, make sure project is not going to suffer hold-ups.

 . --["Tree "][[DateTime(2008-05-07T15:09:00NZ)]] .
 .
== a "Take" Manager ==
Sections of project can be copied, to try out other options. This can be done already, but it is not "managed" by the program. It is like clips, but all selected tracks would be included in the clip, and it could be referred to by another name (scene option/transition option/take n?).

Test playback of options, by choose lead in time and trailing time to check how well it blends in to the rest of the project. Loop play with the extra time at ends. Loop play all options to compare.

 . --["Tree"][[DateTime(2008-05-09T15:34:00NZ)]] .
== a Clip manager (videos) ==
Clips could be marked as per topic, section/scene of video to be used for, percentage the clip is finished, and a rating by the editor of the priority of including it. This section could be made very easy/simple to use. Just a clip manager mode.

Selecting clips can be done without knowledge of the rest of the program, so many more people can help out on this. Good for whittling down on the content.

This is where the non-"video techies" could pop in have a look and cast their vote. Directors, Clients, Managers etc can view and rate the clips. Comments can be attached, and some parameters can be evaluated. Parameters may even be customised by users. They might be interested in "did this make you feel happy, ok, sad?", "would you watch this again?", etc.

This builds director or manager oversight into the project, at an early stage.

If clips were available on the local network, then people can look at them in their own time, from elsewhere (freeing up Lumiera terminals), and make comments. Open Source polling systems could be used.

Use multiple play/viewers to compare in real time (with function to pause while inserts are being played on other tracks, and then start playing again when othe track catches up).

 . --["Tree"][[DateTime(2008-05-09T15:10:00NZ)]] .
== Clip Manager for Audio and Subtitles ==
Allows separate work to be done on "voice overs", effects, other languages, backing tracks, theme tunes, etc. Allows for clips to be linked together as sets. An example set might be the voice over in each of several languages. Each language automatically pasted into the audio track assigned to that language at the same point of insertion as all other languages. Voice overs can be in the same set as subtitles. Subtitles can also be handled in designated tracks like languages.

 . --["Tree"][[DateTime(2008-05-09T15:33:00NZ)]] .
== a "Manuscript, notes, and credit roll" Manager ==
Can be connected with processes in the subtitles manager.

Can be connected with processes in the Work Flow and Project Manager.

Can call up Open Source word processor, publisher, graphics for editing.

Can also manage credit rolls (which might be able to be automatically drafted in the first instance from the project management program and used to check that nobody gets left out).

 . --["Tree"][[DateTime(2008-05-09T15:35:00NZ)]] .
 .
== a "Chapter/Scene collator/splitter" Manager ==
The project could be split up or collated the way chapters are done in word processors.

Each chapter could be rendered to what ever resolution is chosen by the work on that segment.

This rendering could be set to automatic (especially if it is low resolution pixels and frames), or at least done frequently.

All recent renders are available for playing (over network), so the current project can be viewed irrespective of each stages level of completion. Displays may even just be limited to "story board sketches" and script dialogue shown as subtitles (or scans of text as video).

 . --["Tree"][[DateTime(2008-05-09T15:38:00NZ)]] .
== a "Guided File" Manager ==
With a logical splitting of the project into chapters and scenes, or how ever is thought best (and the system could allow for more than one way plus customising), a reference system, database and file system that is coordinated would be very convenient. For example a filing system where every chapter was given a 10,000 number, every scene in a chapter given a 1000 and 100 number and every take given a 10 and 1 number, and every angle given a letter. The notes, record of resources, sites, gear etc can be included for each scene, and viewed as sub-projects. The data could be transportable, so given a global numbering for a large project, dispersed workers could look after their local data. The coordinated default standard for managing the resources would mean that people would not only be familiar with the same program, but also with the same project management, when they go from one site/project to another.

 . --["Tree"][[DateTime(2008-05-21T16:11:38:00NZ)]] .
== Archival Manager for Audio and Video ==
It would be very useful to have an archival footage manager, that can look up footage on various topics (subject, items shown in strip, events). Some of this data could be collected "on the fly" for example, from labels, and clip naming, "cut and paste" temporary clipboard storage naming, timeline (and absolute time). An open source database could be used.

 . --["Tree"][[DateTime(2008-05-26T09:09:00NZ)]] .
== Subtitle editors used as plugins - e.g. Aegisub ==
Aegisub was originally created as a tool to make typesetting, particularly in anime fansubs, a less painful experience. At the time of the start of the project, many other programs that supported the Advanced Substation Alpha format lacked (and in many cases, still lack; development on several competing programs have since been dropped for various reasons completely unrelated to Aegisub) many vital functions, or were too buggy and/or unreliable to be really useful.

Since then, Aegisub has grown into a fully fledged, highly customizable subtitle editor. It features a lot of convenient tools to help you with timing, typesetting, editing and translating subtitles, as well as a powerful [http://aegisub.cellosoft.com/docs/Automation scripting environment] called Automation (originally mostly intended for creating karaoke effects, Automation can now be used much else, including creating macros and various other convenient tools).

http://aegisub.cellosoft.com/docs/About

http://www.malakith.net/aegiwiki/Main_Page

 . --["Tree"][[DateTime(2008-09-12T20:34:00NZ)]] .
== Subtitle editors used as plugins - e.g. BakaSub ==
BakaSub is a video subtitling program that supports Super Station Alpha File formats for titles. It is full featured, containing many of the features of Super Station Alpha.

Many more features are planned, including audio, graphics overlays, video for linux controls, and '''complete plug-in system for extensible features'''.

http://www.allusion.net/wiki/Main/BakaSub

 . --["Tree"][[DateTime(2009-01-15T10:40:00NZ)]] .
----
=== Extract Subtitles and text in format for use as annotations in online video sites like Youtube - text tracks ===

The subtitles and text could be extracted for use as 'annotations" on youtube and other websites.
An alternative is to have an additional text track, that is used purely for online video annotions, independently of the subtitle track(s).
There may be no limit to the number of text tracks that can be added to a project, or the number of languages they can be in, or for what use they are made (comments, subtitles, annotations, etc).
There may be even more uses for text tracks in future.
The "converters" that take the text from a track and convert it to the format for which it gets used (and the menu option to do so), can be handled as plugins - once they become reliable, they can be included as the standard download either for Lumiera, or the standard kit of plugins.
The trick with the GUI is to try to make the windows that handle the range of features, appear as uniform as possible, to keep the user feeling of familiarity.

 . --["Tree"][[DateTime(2009-01-13T16:31:00NZ)]] .
----
== Edits(undo script) used as "white board" for net discussions ==
Synchronise or share edits/takes/scene options etc , used in conjunction with voice calls, or conference calls to effectively act as a white board.

 . --["Tree"][[DateTime(2008-05-09T17:43:00NZ)]].
== Event Alert Manager ==
When a bulky render(batch) or other activity (e.g. in the production stages) is completed, an alert can be sent. When system performance decreases, or stops, a warning can be sent. Warnings and alerts can be any of sound made at local PC's sound card, email, txt message, insert on web page, task bar flashing icon, phone call (auto dialer then play recorded voice message), fax.

 . --["Tree"][[DateTime(2008-05-09T17:40:00NZ)]] .
== an Icon Manager ==
An icon manager would help the user assign story board sketches or scenes as icons for clips, takes, projects, etc. Sets of icons could also be created by users for sharing with users, to lighten up icons that represent clips, sounds, etc that get used for various stages and functions within projects. Icons could also be used to display various statuses on the track timeline.

 . --["Tree"][[DateTime(2008-05-09T15:39:00NZ)]] .
== across the board Resource Manager - also with "Null" data handling, and Templated Video Projects (more use of "undo" script). ==
The location where any resource gets used in a video is handy to know. For example, if an updated version of the video would require that item/object/resource to be changed. Currently the resource management handles "what" the resource is, and "where it comes from", but not "where it goes to". If a record is kept of the resource, its "topic"/"metadata", then the source, processes/procedure, and final result(destination) in the video project can be followed (again and again), and its location in the timeline of the current video can be found.

Using topic"/"metadata" information, it would also be possible to search for "related" resources and work on them. For example, branding features in a video might include certain scenes, overlays, audio, transition styles.

It could feature track and label "like" functions for pinpointing where abouts it goes in the project. Effects and transitions could even be assigned to the "null" data's position/end points.

A system that can manage resources this way, would also help the layout of the project and video timeline in trackview because it would enable the handling of "Null" data at the preliminary stage. The "Null" data can be replaced very easily and included as soon as it becomes available.

Also handy for making "templated" projects, by saving the processes that get applied to the null dat and attached to both ends.

 . --["Tree"][[DateTime(2008-05-16T17:01:00NZ)]] .
== Clip Editing ==
When a clip is made, and saved, it would be handy to be able to re-edit it later if needed. It could be possible to enlarge the clip to include video that was clipped off in an earlier version of the clip.

 . --["Tree"][[DateTime(2008-05-16T17:36:00NZ)]].
----
== Interfacing/Plugging in for Commercially Supplied Products ==
In the case where interface/plugin/compatibility is being made to commercially available products, that the "plugin adapter" for lumiera could also be available for a small charge. Not an exorbitant price even a donation might do - but if Lumiera is going to create an expanded user/client base for a commercial operation then the commercial operation might like to support Lumiera in some way - on the other hand the commercial operation might consider some of the benefits of free and open source software - A model example is the ReactOS operating system who had originally planned to make the OS commercial but were struggling. Now they are doing quite well making the OS available for free, And getting help.

There is also the opportunity for Lumiera to bring on to the project commercial developers that are struggling, by building them into the open source free software enterprise model. It may  get much interest, but a web page that invites interest from businesses that may be thinking about how to jump on board, would show that it is actually an option. There can be protections against businesses that just want to access the code and run off and commercialise it, or seek to exhaust the Lumiera Project of resources or happiness and aalso then run off with it. But where a current business shows serious interest about changing its operational model from supplying product, to supplying services, and from holding onto projects that only move as fast as themselves (during waking hours), to 100's or 1000's of team.

Heh heh 8b  Q: How long before there is a Lumiera "Summer of Code"? (Product development investment)

Donations could be accepted from users who have used the product to make (quite a bit) of money.

 . --["Tree"] [[DateTime(2008-05-20T17:41:00NZ)]] .
----
= Search and Find Functions =
== Find similar sound ==
Sound searches could be made. The user could select a sound (or several examples) on a sound track and search for similar sounds. These could be optionally automatically tagged/labeled with options for names to be incremental or time tagged. The sound could be labeled at the start/end/middle or start and end in/out points. The sounds could be "group selectable".

An example application is ; Here's what a few drum beats sound like. Find all the drum beats in the rest of the track, and add fireworks overlay in the selected video track.

 . --["Tree"][[DateTime(2008-05-14T10:12:00NZ)]] .
== Find similar scene (or shapes in scene) ==
Image searches could be made, either for a total scene or for objects (which may be zoomable).  The user could select aan image (or several examples) on a video track and search for similar iamges. These could be optionally automatically tagged/labeled with options for names to be incremental or time tagged. The frame could be labeled at the start/end/middle or start and end in/out points. The images could be "group selectable".

An example application is ; Here's what a character appears like. Find scenes it appears in, and play a randomly selected related theme tune for that scene. or Find the image of when an event happens in the video, and time shift those events to match with events "found" in the audio.

This may find that some of the object recognition code in the motion tracker would be useful.

 . --["Tree"][[DateTime(2008-05-14T10:18:00NZ)]] .
== Find scene changes ==
There could be a function to detect scene changes. It might use code from the motion tracker. The user could have options to set criteria for the amount of change required to trigger a scene change detection, or what objects have to move/appear/disappear. The detected changes could also be ranked relative to each other by tha amount of change, and when a clip is going to be inserted the scene change locations, could be used as suggested insertion points.

 . --["Tree"][[DateTime(2008-06-05T19:44:00NZ)]] .
----
== Printout Feature ==
There are no facilities for doing a printout of any sort. Printouts of the trackview, story line/board (yet to have this feature), and screen grabs of particular window panel settings. Put the printout posters on the wall, so the whole team can "mindmap" over it. Window panel grabs are helpful for making tutorials and helpful instructions, share your settings ("your settings should look like this").

 . --["Tree"][[DateTime(2008-05-24T12:15:00NZ)]] .
== Easy and obvious Still Picture export method ==
There are no facilities for doing a still picture grab from the video. This could be a button in the composer viewer - click it during pause to grab a single frame, hold it down during play to grab a sequence. The "Translate" option in the "video" menu of track view could be able to do it maybe, but I've not tried and it doesn't look all that obvious or easy.

 . --["Tree"][[DateTime(2008-05-24T12:23:00NZ)]] .
== Easy and obvious Still Picture import and handling method ==
There are ways to currently bring an image into the project and use it for watermark, titling, credit roll, etc. A still image manager would help to import the still images associated with the project. Default directories could be used to let Lumiera know where it can go on the hard drive to look for images, but this could be messy if the images are to be found amongst the rest of all the other user's pictures. It would be better have have folders that the outside graphics programs can be told to save to, file managers can drag and drop to (copy and paste), and maybe emails save attachments to, and shared network folders can accept work from the graphic artists down the hall.

This fetaure would probably work best with the rest of the "Resources" management.

 . --["Tree"][[DateTime(2008-05-24T17:13:00NZ)]]
----
== Interactive Recording Mode - Record during Playback ==
Just like some multi-track sound recorders, it might be possible to have the ability to playback and record at the same time. This would enable actors to record their separate parts, or a first take scene, but from there on after they could do additional takes individually and remotely. This means that touching up and fixing problems becomes far easier and convenient. Actors could also play their part in real time with 3D effects, virtual characters (pre-recorded), and animations (made by stop motion).

It is also useful where the video or sound effects may be created live and manually, and thus require the experience of the live played back track for the operators to respond to.

In a situation where it might be desired to record the sound track first, the actors could recite their parts at the musically cued times. The music is played back, while the voices are recorded.

 . --["Tree"][[DateTime(2008-06-04T19:28:00NZ)]] .
== Interactive Recording Mode - Interact with Midi Sound Track ==
The user might want to identify frames of the video that could be used for timed events in the music track - either for determining the beat, or for instrumental effects. Some method of coordinating the music/midi systems with the video frames would be handy - maybe dedicated labels or keypoints.

 . --["Tree"][[DateTime(2008-06-04T23:27:00NZ)]] .
----
= Ideas Handling Processes =
== Date entry for these pages ==
It is difficult to add the author and date in a consistent format, in these pages. Smilies are easy to add ;-) , but not whos smiling or when. It can be done with the text edit mode. But some visitors may not be comfortable with that. A button at the top of the Gui Editor could solve the problem.

 . --["Tree"][[DateTime(2008-06-11T11:56:00NZ)]] .
== Data entry form for ideas - optional entry method to help processing. ==
It is great to have a free flow brain storming page like this one. There's no guarantee of usage or obligation to implement, and maybe get considered - but also anyone can use it, and there's no holding back. It's like cooking soup - the stove is fired up, a clean pot is on it, the water is added, the veges, meat , spices, sauces, bits and pieces get prepared on the bench. Every body can suggest, some will choose to prepare, then there's the "hum" and the "hah" about what goes into the pot. Any left overs can go in the fridge for then next brew, or you can add them to your own dish "to taste".

How does that old saying go? ;

"Many cooks, make light work"

It would be convenient for the decision makers who assess ideas, to have them already in a format for processing. It is also good to not burden "idea submitters" with processes and formalities, when all they are wanting to do is pop in and drop a note in the suggestion box. If there is a form method of putting ideas forward, then some may be happy to do a little extra work, by using it. The entries in the form can be cc'd to the brainstorming page (to help spark ideas in other visitors).

Use of metatag topics would help developers scan the ideas for areas they are working on. People who aren't developers, but have enough technical appreciation could go through the ideas and categorise them with relevant (maybe standardised) keywords, and ratings of importance/complexity. So this takes the "clerical" work away from developers, and makes their work more effective at targeting where their next efforts get applied.

Could attach pictures.

 . --["Tree"][[DateTime(2008-06-11T12:00:00NZ)]] .
== Ubuntu Brainstorming System scripts available as Open Source for anybody - could be useful here ==
Ubuntu is running a Brainstorm site at;

http://brainstorm.ubuntu.com

Their code is available and gets regularly updated.

This might be the page teh code is available form;

https://code.launchpad.net/~ubuntu-qa-website-devel/ubuntu-qa-website/trunk

See info also at;

http://dbzer0.com/blog/setting-up-a-brainstorm-clone

http://digg.com/linux_unix/Ubuntu_Brainstorm_Launched

The Ubuntu Brainstorm system is constantly improving. Currently it uses a yes/no voting system for ideas.

This may later be expanded to include "don't care/null" vote, scales of yes/no, votes on ideas (ideas that get presented as problems/comments/pros/cons) instead of votes on submissions only. The system handles ideas that are optional alternatives of benefit to some (with no negative impacts for others) the same way as ideas which when implemented "force everybody" into the same solution. A good system would allow for situations like "well if that's what you want to do, you can do it, we'll included it if we don't have to use if we don't want" - a bad system works on the basis of "This is how it's going to be for everybody - Like it or Lump it".

--["Tree"][[DateTime(2008-06-27T09:53:00NZ)] .

== Meeting and design project Processes - Groupware and Project Management Freeware open source ==
The project processes might be streamlined and assisted by the use of groupware and project management software (open source).

 . --[:Tree:Tree ][[DateTime(2008-05-31T18:46:00NZ)]] .
----
== Meeting Processes - VoIP Multimedia ==
VoIP technology could be used for remote contributors.  Ekiga, TeamSpeak and Linphone are possibilities and some do video conferencing. The oral discussion could also be transmitted live over IceCast, Shoutcast, Peer2peer, and be available for download. If the archives save the discussions by topic, then these can serve as reference resources. The audio files might ven be able to be send through voice to text recognition software for automatic transcription - saving time - great for keyword lookups.

 . --["Tree"][[DateTime(2008-05-09T18:37:00NZ)]] .
== Handling Ideas through to Final Code ==
This brain storm page is a great start. It allows loose format collection of ideas. It would be handy to have a (flow) diagram of the process that is gone through from submission to rejection or inclusion in final code. Times passed through each stage could be recorded. Salient points of discussions noted - which probably become points pf relevance/importance which get weighed up when evaluating decisions.

So maybe this could include a rating system for each idea for its importance, level of commitment(resources people time), level of expected result performance (speed of using, user happiness,flexibility of program, etc). Any other factors for rating. Ratings by team members, by users, by users of other products, by novices, by non users.

The ratings by non-users, and users of other products rating's might help differentiate what the reasons might be why people are not preferring to use the program.

Rate this idea;

-5 -4 -3 -2 -1 0 1 2 3 4 5

Show the frequency of votes for each rating level (also cumulative, average, and variance)

One for users, another for non users.

Reasons for ratings can also be gathered.

Problems associated with a project can also be identified (by team, or anybody). Solutions can be suggested, resources offered/assistance given. So a parked project instead of "gathering dust", can "gather momentum" because although there may be no one willing to work on something at the time it is suggested, or any foreseeable time after that, anybody can still find the project. And if they can see that if they put their name down, or offer help, than when the critical mass for "go" arises, then it will begin. So even parked projects can happen. The projects can be cross referenced as to what skills, resources, etc are needed for each project. So if somebody wants to help in some way, they can easily find what projects match their type of contribution. Join a "project team", join a "skills group", join a "resources supplier group", join as a "project sponsor". The "About" page in the help file could have a credit roll (Lumiera generated, with major sponsor logos) for all contributors. Um Er or emulate a propriety OS with a credit roll "easter egg". You could even have a competition for the best credit roll, download the latest credit roll, include recent announcements and news.

 . --["Tree"][[DateTime(2008-05-09T19:04:00NZ)]] .
== Redundant development system more fail safe ==
Peer group code review/checking. Work on one project - be a reviewer on another. This also helps make sure commenting of code is helpful. A team of "trouble shoot" problems, and provide temporary help in projects that have hickups - liaise with over all managers. Treat this as a learning experience for everybody. Mentors (expert programmer), and Patrons (somebody from video industry or amateur, groups) for project teams. Bring novice programmers onto the teams, let schools and students join, have small projects that learners can use as exercises, extract code snippets that serve as good examples. The projects can be used as examples of how good the software is that is being used. The projects can also be part of the training ground. Maybe allow for programming in other languages that can be translated into the languages that are being used. Determine what "artwork" may be needed early on, define its format, so that it can be done concurrently. Artists can understand that their work may not be used if a project stops, but it could be re-used in another project. In any case a gallery of art work (used, unused, and under development)can be made, along with a gallery (archive) of code - "Every thing is beautiful in it's own way".

 . --["Tree"][[DateTime(2008-05-09T19:49:00NZ)]] .
== Could start forming a Users group Early ==
(even before there is a program ready to use)

The users form part of the "roll out" of the program, some will be willing to use the "alpha" versions. An approach using a.s.a.p delivery to alpha users will be able to make use of their feedback and observations early on in the development. Have the users all ready and waiting before code is drafted. Rather than finish code and see who downloads it and then gets back to you.

Form user groups with evaluation kits (forms easy to fill in) to measure performance of the program. Run the program in debug and diagnostic mode.

Make the feedback process part of the program, and automatically get the state of the program before it crashed/hung.

Just like context sensitive hover of pop up help (that can be edited), the program could solicit suggestions at each stage of its use. So the user doesn't have to use some form of arbitrary language to say "I clicked on,window looked like, right click, icon , ..." - the program would detect exactly where they are and have recorded processes they went through to get there (the "undo" script is handy for debugging). They only need to describe how their system responded (and even that information could be automated). At a guess several components to implement this kind of approach may well already be available.

 . --["Tree"][[DateTime(2008-05-09T19:21:00NZ)]] .
----
= Frame-Precise Editing Features for Faster Workflow =
== Automatic Clip Creation based on video content. ==
When scanning through an hour long video clip, it can be tedious to go through it all making clips.  It would allow the user to get right to work if Lumiera could split the video into clips based on scene changes.  Each clip would begin at precisely the frame the current shot begins and end at the last frame before the next shot.  As long as the user could then edit these clips on the timeline, this would decrease the time spent sifting through the raw footage.

Comment: This seems like a good idea, and quite easy to implement. I think that when we get the video-capture and media manager code working this would a be a good subproject for someone to take on.

 . -- ["joelholdsworth"] [[DateTime(2008-07-19T19:42:04Z)]]
== Jog feature. ==
A jog tool is a sliding ui element that when clicked and held, will play the video at a certain rate as the mouse drags left or right.  As the mouse drags the the left the video plays forward faster (It should advance very slowly at first.).  It acts the same way when the mouse drags to the right, except that the video plays in reverse. Again, it can be tedious trying to make frame-accurate cuts to long video files.  Without a jog tool it makes it more tedious to get to the exact frame you want to cut on because you must scan through, then click the next frame button half a dozen times.  A jog tool would remedy this because one could easily vary the playback rate, even reverse it, zeroing in on the frame much more quickly. Together these two features could really increase the speed at which one can edit precisely in Cinelerra.

Comment: This idea seems feasable, it could be worked together with cehteh shuttle slider proposal.

 . -- ["joelholdsworth"] [[DateTime(2008-07-19T19:42:04Z)]]
== Justified Inserts ==
I am a AMV (anime music video) editor where precise timing to music is absolutely necessary (Anything off by 2+ frames is quite noticable). Therefore, I would like at least 2 different kinds of insertions: left justified and right justified to simplify the syncing process. Left Justified is how Cinelerra currently does everything. It should be the default insertion rule. Right Justified means that the end of the clip lines up with the end of the out point. This is intuitive if the out-point is used to select a clip in the viewer window.

Center Justification would be very useful, but it would not fit into the paradigm of three point editing and therefore should be considered with care. Instead, four points would have to be specified: the selected point in the viewer, an in point, an out point, and finally a center point. The selected point in the viewer then lines up with the "center point" in the timeline.

 . -- -- PercivalTiglao [[DateTime(2008-07-16T02:32:58Z)]]
----
= Not GUI Related =
== Ubuntu Developers repository service? ==
Ubuntu has a service for software projects to store their code. Its public front end looks like a repo. The back end gets updated by the project owners, who don't have to go through the "red tape" process each time. It also has built in systems for user feedback, bug reports and updates. see;

==== Canonical Announces Launch of Launchpad 'Personal Package Archive' Service For Developers ====
http://www.ubuntu.com/news/launchpad-ppa Extracts ; "The PPA service is the newest feature of Launchpad, Canonical's hosting service for public software development. Launchpad is fast becoming a centrepiece of the free software development process, allowing users to report bugs, contribute code, submit translations and generally collaborate in an efficient and transparent fashion. PPAs enable developers to publish ready-to-install packages of their software directly to users." "Developers can use PPAs to publish their own versions of popular free software, or to create packages for software they produce. Individuals and teams can each have a PPA, allowing for collaboration on sets of packages. Canonical provides each free (“libre”) software user with up to one gigabyte of free Personal Package Archive space, which works as a standard Ubuntu software package repository.

PPAs give developers the opportunity to distribute packages to a much wider user base for testing than is normally the case. Packages published in a PPA are easier to deploy and keep updated in complex environments. Users who are interested in those packages can make a single configuration change to their systems to enable them to install packages from that PPA.

“Many developers want to modify existing packages, or create new packages of their software. The PPA service allows anyone to publish a package without having to ask permission or join the Ubuntu project as a developer,” said Christian Reis, who leads Launchpad application development. “This removes a significant barrier to contribution in the free software community. "

=== "Getting Started ===
The Launchpad PPA Service is available for general use starting on November 27, 2007 in line with the regular Launchpad release cycle. Browse existing Ubuntu PPAs at:

https://launchpad.net/ubuntu/+ppas

Users with Launchpad accounts can get started with PPAs at:

https://help.launchpad.net/

https://help.launchpad.net/PPAQuickStart

Software in Personal Archive Packages will be built for x86, AMD64 and LPIA architectures against current versions of Ubuntu."

== A "Build Server" service at Ubuntu PPA ==
Ubuntu's server can compile the project's source code for each architecture, and Ubuntu versions, taking the burden off the project team, for compiling for architectures they may not even have.

It might be possible to have a chron job to send recent (range of alternative) package versions from Git to Ubuntu's PPA, or GIT manager scan trigger the update manually.

https://launchpad.net/ubuntu/+ppas http://fridge.ubuntu.com/node/1125

(ichthyo will take care of the Debian packages for Lumiera) . --["Tree"][[DateTime(2008-07-14T13:14:00NZ)]].

== A "Build Server" service at Suse ==
http://en.opensuse.org/Build_Service (ichthyo will take care of the Debian packages for Lumiera) . --["Tree"][[DateTime(2008-07-14T20:55 :00NZ)]].

== Ubuntu Launchpad - Bug Reporting and Feedback service for free software projects. ==
The Ubuntu Launchpad bug reporting service is free for free software projects. It acts as the public front end for user bug reports on project files, and their shared dependencies. It accommodates cross-project liaison so overlap problems can be sorted out more easily, and projects can share code and build interfaces to each other.

You might need to log in. "Take a Tour" of the system to see what it has to offer.

 . https://launchpad.net/
 . --["Tree"][[DateTime(2008-07-14T15:11:00NZ)]].
== DrQueue render farm manager FOSS. ==
DrQueue is a powerful open source distributed render farm manager, used for a range of applications across the visual effects industry and for general batch processing jobs in science, engineering and finance. This is used with Blender for rendering. It might be handy as part of the kit for Lumiera, to help with distributed jobs over a network.

see  http://drqueue.org/cwebsite/index.php

 . --["Tree"][[DateTime(2008-07-18T22:46:00NZ)]].
= Won't Implement =
== Burst frames to graphics card. ==
I am not sure how the current video play system works, but speed might be increased if several frames got sent to the video card at once. The video card can act as a video cache and play them as required. The number of interrupts to the process is reduced, to much less than one per frame, freeing up more CPU time for calculating the effects etc..

 . --["Tree"][[DateTime(2008-07-18T18:18:00NZ)]].
Comment: Good idea, but not really necessarily. Firstly becuase XVideo is pretty fast, and the bottle neck is in rendering not drawing. Second, we can't get direct access to video RAM anyway because X abstracts it away.

 . -- ["joelholdsworth"] [[DateTime(2008-07-19T19:42:04Z)]]
----
== Comments for Developer's page items ==
Only developers can comment there.

1) Re: Build manually applied User Precautions into the program.

Explanation to help " I'm not sure I quite understand what this is about. Your explanation is a bit hard to read."

 * User Precautions get built out of user interface and into program.
 . When attaching such and such effect to a track, disable "play" before attaching it, then re-enable play aft attaching it. (we don't tell you this before hand, and we never will, unless you ask the question and search the net, then you might find out in the "secrets manual", And you'll have to remember this (always)!! If there are circumstances that apply to an effect (or for that matter any other part of the program), then the feature could have a flag in it that warns the system to take note of it, and it then reports what its requirement or tweak feature is, so the system can automatically handle it the best way. (A sort of OO process handler). This not only saves potential lengthy wastes of time, but saves concentration on sideline issues, speeds up work, adds to reliability and good time user experience.
 . --["Tree"]2008-05-07 21:34:00 .
  . Comment: I'm not sure I quite understand what this is about. Your explanation is a bit hard to read.-- JoelHoldsworth 2008-07-24 16:24:50
  . . Comment: The above info is from instructions (out of "Secrets of Cinelerra", I think), and is to be done when attaching certain effects to a track.
  . As you can see the instructions are lengthy. The situation that it needs to be done at is always (software) detectable (ie the effects gets selected for attachment), so the precaution could be built in to automatically be done, rather than by the user.
  . Tree 2008-07-25 15:07:30
2) Re: Visual prompts for icons to indicate effects

 * Help and visual prompts use GIFs for visual cue as to time behaviour of feature.
 . Icons are handy when they portray some sort of cue for the task that they do. A number of tasks in video editing are time related. It would be handy to have some form of visual que as to what the time related task does. Since Gifs can show motion, they would be very good for this task. PNGs could also do it it they were timed to cycle through their images. Example uses would be to show the difference between "track" and "stabilise" in motion tracker - a strip showing a pogo stick going along a footpath would be suitable to show the differences between track and stabilise (and could also be used to show the differences between the forms of vector calculation. GIFs could also be used to show editing functions that involve several important steps.
 . --["Tree"]2008-05-26 08:45:00 .
  . If we did want animated icons we'd be better off with MNG or a PNG image strip because then we'd get transparency. There are 2 reasons why I think this is a bad idea. 1. There's an aweful lot of drawing to be done. We already need to produce perhaps 100 high quality tango style icons for the user interface. If they're animate someone would have to draw 1000s of these, with all the quality control problems that go with it. 2. I'm not sure it's something people will find very helpful. Even if the animation only begins when we hover over the icon, it could even be quite annoying and distracting.-- JoelHoldsworth 2008-07-23 20:39:36
  . . Comment: I was thinking that the effect could be applied to a video, and small resolution copy made of the video using every "x"th frame, to build the gif of png - no hand artwork required. This idea is for effects.
  . But the pogo stick example was also specifically for the motion tracker, as it would visually show the different types of tracking available.
  . Tree 2008-07-25 15:08:30
3) Re: User feedback and collaboration for help system

 * Help System - available for user improvement
 . Similar to tool tip and status bar suggestion above.''A''' "hover" hint / help''' facility would be a major bonus. Just make the function available, the box can start with an index number, and users can type in their own help comments (either in a''' help text entry management '''section, or directly into the pop-up hover box - in optional help edit mode). ''
 . These can be pooled at a central web site in to languages, and brevity/completeness (options to links to further help, links to examples, links to video tutorials). So the developers do not have to spend time writing help files - just make it possible for the users to. The developers might like to add a few comments to the verbose files at some later point, or clear up inaccuracies. translators can also do the work for other languages. Very quickly the supporting documentation's usefulness would add to the attractiveness of the program.
 . -- ["Tree"]2008-05-07 16:44:00
  . A wiki style approach is often an effective way to get community input on documentation. This may be a good way to get people working on it. But it's best for us to publish a tidied up documentation set and ship that, instead of creating a complex editable help system - which is vulnerable to vandalism.-- JoelHoldsworth 2008-07-23 20:29:25
 Comment: This process has several stage - (1) the user can edit their own helpfile locally, (2) they can upload copies of their additions to Lumiera's site (or in this case copy and paste them {automatically?} to the   Wiki   ), (3) Lumiera Website Staff can make those available on the web site (after scrutineering to avoid vandalism) , (4) other users can download the new additions to their own PC (they could also translate them, and vote on which one best explains a similar topic), (5) the latest cumulative help file is included in updates/upgrades.
 . Tree 2008-07-25 15:16:30
4) Re: User chosen experience levels

 * User selectable Experience Level - Task Oriented Layout
 . The user could be asked to choose their experience level, and more complex options then get greyed out. The user could be asked the common tasks that the want to do, and other options could be greyed out. They can choose whether they want "grayed" out options to be available, or viewable, or not. The options which are advanced (or 2 levels greater than their current expertise level) could be "dark grayed" out and the user could have similar choices about their display) .
 . --["Tree"]2008-05-09 20:50:00 .
  . Comments: I can't see any good reason for this. The user interface ought to be usable for everyone. The problem is that we want to enable everyone to be an "expert" by making power intuitively available even to beginners. The other problems is that light users might use only 10% of the functionality - but different light users use a different 10% from each other. So hiding things doesn't actually help make things simpler. It's much better to have things tidily arranged with clear descriptions etc. to help the user understand what a command might do - rather than hiding the command from them.-- JoelHoldsworth 2008-07-22 22:25:58
  . Comment: Word Processors do this kind of thing with menu customization, and desktops do it with panel customization. It's no so much a matter of "hidding" the options, as keeping the options available, with a "visual indication" that the user "typically" does not need to bother adjusting the setting.
  . Tree 2008-07-25 15:08:30
5) Re: Settings set to "most likely to run, for most people" at install - only need to tweak Up for speed, rather than Down to work.

 * Default settings after install set to most reliable and least requirements
 . The program may be tweaked to get performance on PC with great graphics systems, plenty of Ram and good hard drive speed. For people with lower spec'd gear, there may be some tuning needed, just to get going. There is the likelihood that people with low spec'd gear are not so able or inclined to read up on their hardware, and "search" for help on their video editor, to find out the solution to a problem (which they may not even have much idea of what the problem is). Consequently, they are likely to give up and not use the program.
... through to ...

 . Feature to save different hardware settings, with notes in the hardware specs, and share them. Upload to Lumiera web site, so that better first guesses for new users are available. And if an intelligent system is used for hardware detection in future, then the information for best choices will already be available.
 . -- ["Tree"] 2008-05-28 09:41:00
  . Comment: The problem is that unlike games, in movie editors there isn't very much that can be done in the way of tweaking. With video editing, by and large there are no shortcuts. So the calculations that must take place to render a video on a Quad Core workstation are the same as the ones that need to happen on an EeePC. Lumiera needs to be intelligent about how much RAM it uses etc. but that sort of thing ought to be automatic. The only thing that this could apply to is reduced quality previews, which I've put in the blueprint list.-- JoelHoldsworth 2008-07-24 16:34:20
  . Comment: True - there are not many things which can be done, but what can be done, can make a lot of difference. But a newbie would probably have no idea what to do to make it work when it doesn't. For example in Cinelerra;
  . a) OpenGL - does one need it, and if so how to get it going so that it works faster (may need to get a better graphics driver)
  . b) Use color resolution that is within your machines capability e.g rgb 16bit, noting that rgbA16 bit is useful for some effects so try that.
  . c) not to be extravagant with sound resolution that you will never use.
  . These few things would help a newbie, get going straight away. I know because I went through some nail biting disappointments before I figured this out - I could not afford to have a Cinelerra that did not work - now it goes wonderfully - hardly know what crashing is - but it took tweaking that if it came installed that way would do wonders for the program's reputation. But it's just a suggestion.
  . Tree 2008-07-25 15:37:30
6) Re: Macros

 * Usability (ease of use) - mouse clicks and motions, inputs decisions, etc required to achieve tasks. Macros are really handy for allowing the user to speed up repetitive tasks that the program designers have not anticipated and made easy to do from the outset. Macros can be shared on a central web site. Plus developers can look and see what the macros are being used for, as this gives a very important indication of where vital tasks are.
 . -- ["Tree"]2008-05-07 16:44:00
  . Comment: We need to have some discussion about scripting. To do macro scripting we'll need to implement a DOM interfaces etc. into 2 or even all 3 layers of the system. If we want to do this, then we'll need to begin planning for it early. We have talked already about making scripting the movie itself AviSynth style. Both are worth talking about.-- JoelHoldsworth 2008-07-22 21:58:22
  . Comment: The undo system records the actions. I am not sure how the undo system works. The actions can be obtained from the undo system. The user could then edit the actions, to compose their macros. Maybe not everything could be macro'd, but what ever "can" be macro'd in the first instance, is a good start.
  . Tree 2008-07-25 16:30:30
  .
7) Re:

 * Navigation Systems
 . There may be several methods to make menu selections, and other choices. The Gui could be made quite adaptable/customisable. Using a "skin" approach to the Gui, would provide a system for users who are '''not programmers''''''''', to help develop improved user interfaces. Mouse "gestures" (may be patent considerations) are another option. The way that options are communicated with the program functions could be made so that even as yet undesigned "user chooser systems" can be added. '' ''
 . -- ["Tree"] 2008-05-14 08:40:00
  . Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone!-- ["joelholdsworth"] 2008-07-21 21:58:48
   . I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile.
    . -- ["ct"] 2008-07-22 07:11:11
  Comment: The objective of the suggested system is to allow Non-programmers to help contribute, which takes some of the graphic and ergonomic workload from burdening the programmers. Non-programmers are unable to help otherwise, so it doesn't matter if they do this, especially if they understand they may be overlapping each other, or their work may get dumped anyway.
  . This system allows the non-programmers to try out their GUI(s) to a high level of confidence before they send their code along (and waste developers time with bugs or confusions). So they can make their mistakes, and jiggle their components about, and eventually get it right. '' ''
  . . Please think again about "Everyone" - not everyone has the same skill or need. With a little flexibility in the program, it can be many things to many people, but not at the same time (modes of use concept) - but Many people would like it, because it "can" suit them.
  . It's a bit like the average family household - how many people have 2.25 Children, 1.7 televisions, and 2.1 cars - hazarding a guess, very likely None.
  . But if there is a choice between 1,2 or 3 Children, and 1 or 2 TVs, and 1,2 or 3 cars - a great many people would be included.
  . Tree 2008-07-25 17:20:30
== Strip handeling ==
Have an infinite number of multi-purpose video/ audio strip layers like Blenders video editor. no need to add or remove channels.

simplify keybord shortkuts for workflow improvement, map the most importent shortcuts directly to keys, with no useless modkeys.

compositing handled using nodes(blender).

modal editing, AKA Vi/Blender.

(somebody, sometime)

----
== Similar GUIs of other Linux Video Editors ==
a) Open Movie editor has a GUI that is similar to the GUI shown at the top of this page.

http://www.openmovieeditor.org/

Note tabs which allow space not needed for other (mutually exclusive) tasks, to be used for the current task.

http://www.openmovieeditor.org/images/screen_shot_main.png

b) Vivia, a video editor for windows and linux, also has a similar GUI , except the resources and viewer are swapped sides.

http://vivia-video.org/

Note tabs on right hand side, which allow space not needed for other (mutually exclusive) tasks, to be used for the current task.

http://vivia-video.org/screenshots/resources.jpg

c) KdenLive has a similar GUI

http://www.kdenlive.org/

Note tabs which allow space not needed for other (mutually exclusive) tasks, to be used for the current task. http://kdenlive.org/images/kdenlive-0_5.png

d) GUI for LiVES - Linux Video Editing System

http://lives.sourceforge.net/index.php?do=features

http://lives.sourceforge.net/images/livesmt.png

e) GUI for Kino

http://www.kinodv.org/

Note

i) tabs on right hand side, which allow space not needed for other (mutually exclusive) tasks, to be used for the current task.

ii) the tabs are not in the order that might be used most commonly. Such as Capture, Timeline, Trim, Edit, Effects, Export.

iii) the tabs are organized so the each major step in the video editing (part of the production process), is given maximum screen space, with little displaying of information from other steps.

http://www.kinodv.org/ezimagecatalogue/catalogue/variations/17-300x300.png

Concept for "overall" GUI design, for the full range of tasks in the process.

The desktop of a PC that is being used for video production, is likely to have many tasks going on. A task is easier to perform if it is easy to get to the window. and get to the zones in the window that are needed for the current chosen task. It is correct that a simple program makes the task simple, but there are other tasks to be done. There could be benefits to considering the overall picture of all the tasks that will be likely to be done "in relation to" the video editor program itself.

Note on layout

The above layouts were designed when CRT displays were the norm (ratio roughly 4 wide x 3 high).

The new LCD screens are much wider. With the viewer and resources areas next to each other, and above the track view, there is likely to be some wasted space above the track view, and the tracks will be forced to narrower heights, or less viewable at once, than the following alternative proposed layout.

A better layout for wider screen LCDs would be to have a full height trackview, and the viewer and resources placed on the side (probably the right side), one above the other (probably viewer above resources). This would allow the tracks to either have bigger thumbnails, or have more tracks displayed.

Another advantage is that the tracks being viewed, could be scrolled, while holding the viewer still in view.

This could be considered to be the "standard" view.

It might be possible for the view to be managed as modules (like email viewers), so the user can either place the modules where they want (within the winndow), or choose from a range of predetermined layouts.

Use of tabs Just as the use of tabs makes for efficiency of space for the tasks of editing, so they can also be used for additional tasks and features that involve a series of steps in their procedures. For example node and transition edits can be designed in separate tabs, given a name, and then applied to the trackview (with only some of the parameters needing to be adjusted). If the program is/will be likely to encompass many more of the tasks involved in video production (such as knowledge management of a multitude of clips), then a layout that has a tab bar already in it, will allow for an obvious (intuitive) place for functionality to expand in.

. --["Tree"][[DateTime(2008-08-25T19:07:00NZ)]].

== GUI of FORscene (commercial software for web-based editing) example of windowed view and track view ==
FORscene by Forbidden Technologies http://www.forbidden.co.uk/
This is a multi-user web browser based editor.
Notes;
1) each task has its own window, which gets messy with more tasks being open, and ties up the user with sizing and moving the windows, whereas tabbed windows would give more space for each task and allow easy jumping from one task to the other.
2) The track view has an icon at the right end of the track to indicate what "type" of track it is (e.g. video, audio, subtitle, comment, projector/output, etc)
http://upload.wikimedia.org/wikipedia/en/c/cc/FORscene_editing_interface_May_2006.PNG
. --["Tree"][[DateTime(2009-01-31T01:41:00NZ)]].


== Jahshaka GUI ==
The Jahshaka video editor GUI is complex due to the power of the editor.
http://jahshaka.org/

Two points to note;
1) The Layout is "centered around" the view, rather the than the time line. This is a similar approach as for the Cinelerra camera/projector viewer, which had many of the "tools necessary to carry out the tasks for that mode of use" immediately at hand around the perimeter of the view window.
The layout of "Smoke" approaches a similar concept (see http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7927825 ).
2) The features available for use are not all always immediately relevant to the task being done, and so take up space, but there is good use of "tabs for switching mode of use". Some of the items which remain in view when a "mode of use tab" is switched, could be included in what gets removed from view when the tab is switched. Consideration of what tools/fetaures are need for each mode of use, would help optimise the view realestate for each mode of use. The ability for the user to customise each view (including what is switched in/out of view) allows the user to most efficiently use the program for the various tasks they need to do in order to complete their project.

http://jahshaka.org/plugins/p17_image_gallery/images/24.png

For more Jahshaka GUI images see http://jahshaka.org/gallery/p17_sectionid/2/p17_imageid/29

. --["Tree"][[DateTime(2009-01-31T10:15:00NZ)]].


== Movie Masher - Web front end system ==

Movie Masher is free open source software that can be installed on any web server to enable advanced video editing features for end users.
The goal is to provide custom client-side user interfaces for a wide range of third party, server-based video editing applications. The controls that make up each interface can be easily skinned with new graphics, arranged arbitrarily within shaded panels and even removed entirely for simplified, single purpose interfaces.

Online video editor implemented in ActionScript 3 (AS3). Provides client interface and simple API for server interactions. Supports sequencing, trimming, time shifting, compositing and mix-ing. Interface can be reskinned and can be functionality extended.

Lumiera could use this system to provide a web based frontend, for those that may want it. This system may not require much work by the core Lumiera team, because the way this system works is "to provide custom client-side user interfaces for a wide range of third party, server-based video editing applications". The main Lumiera engine is controlled by functions which can be scripted, and are accessible from the GUI, it is only a matter of providing the specifications of the communication between GUI and Engine, and the team at Movie Masher could make a module extension in Movie Masher to use for Lumiera.

http://www.moviemasher.com/feature/
http://sourceforge.net/projects/moviemasher

http://sourceforge.net/dbimage.php?id=130291

. --["Tree"][[DateTime(2009-01-31T10:05:00NZ)]].
----
== Some windows GUIs that are similar to the current Lumiera layout ==
=== Wax - free windows video editor ===
Wax video editor (possibly compatable also with win98).
Has plugins and some compatability with Zwei Stein.
http://www.debugmode.com/wax/

http://www.videohelp.com/toolsimages/wax_2_574.jpg

--["Tree"][[DateTime(2009-01-31T01:22:00NZ)]] .


=== AVItricks - sharware windows video editor ===
Windows video editor. Classic version is available for free.
http://www.bobyte.com/AviTricks/Help/Default.htm
http://www.bobyte.com/
The image shows track editor and viewer, as well as tree structure for application of effects.

http://www.bobyte.com/AviTricks/Images/AviTricksc.JPG

--["Tree"][[DateTime(2009-01-31T01:24:00NZ)]] .

=== AVI Edit ===
Windows 95 !! and up compatable video editor. Works on very low sepc machinbes (P166MMX, 1GB HD and 32MB Ram).
Trialware, $25 after one month.
http://www.am-soft.ru/aviedit.html

http://www.am-soft.ru/huge_screen.gif

--["Tree"][[DateTime(2009-01-31T01:28:00NZ)]] .

----

== GUIs for OSX Video editors ==
=== Hyper Engine ===
Hyper Engine is a GNU video editor for Mac OSX, which can do capture also.
http://sourceforge.net/project/screenshots.php?group_id=131273
http://sourceforge.net/projects/hyperengine

1) Trackview, trackview summary, and projector view shown below.

http://sourceforge.net/dbimage.php?id=20337

2) Live capture window shown below.

http://sourceforge.net//dbimage.php?id=20351


--["Tree"][[DateTime(2009-01-31T11:41:00NZ)]] .
----

== Videos, Audio, Clips and Resources Manager by using plugins for FOSS GPL "Library & Collections Management" programs. ==
The video and audio raw material, clips, etc could be managed using code that is already available in project that carry out the same tasks. For example as library managers, or media  (video, audio or CD) collections, Integrated Library Systems (ILS).

Examples of a library management program ;

a) Kete - http://kete.net.nz/

b) Koha - http://www.koha.org/

c) Greenstone - http://www.greenstone.org/

d) Evergreen (OpenILS) - http://open-ils.org/faq.php

e) The Scout Portal Project http://scout.wisc.edu/Projects/SPT/index.php

An additional benefit to using "library" managers, is that it '''''can handle interloans''''', referencing of "other" (people's/organization's) libraries, numbering systems, descriptions, and classifications, thousands to millions of items, search systems, review and comment systems, plus the benefits of open source that allow the expansion of features easily.

The use of task oriented programs in this way, makes use of established code, that has been developed by experts in their field. Any database system would be useful for managing all these media. But one that has been developed by the people that have been working with cataloging systems for a long time is likely to do well. Plus it can be readily improved, by people who do not have to know the first thing about how to design video editing programs. The program also gets improved because of it own community, which '''''adds features or performance to Lumiera, without even having to "drive" the development'''''.

see Clay Barnes's article on intuitive user interface http://www.hci-matters.com/blog/2007/07/07/search-isnt-the-future-or-why-the-gui-is-so-approachable/

Since media archives/catalog management is important in the industry, any efficiencies provided by this function are likely to make the program more desirable.

There may be the possibility for a choice of catalog management system, as the databases store very similar information, and most libraries are capable of viewing and searching the catalogs of other libraries. This would help a large production operation to transfer their catalogs for use with Lumiera.

As with all plugins, if the plugin can be used as a stand alone utility/program, then the user could begin just by using the plugin, and may choose at a later time to migrate to using the full program. This makes for a more confident and safe transition from old systems to new. So a business/studio could begin by using the cataloging system to archive all the clips and resources, then progress to using a program that can directly connect with the data (ie Lumiera - or others that use the plugin system developed by Lumiera - and other linux video and library projects).

Another interesting feature of the above library programs is that some of them include the ability to "write reviews" of the material. It would be just a relatively small step to include voting features. But combined with the already current feature to "issue the media (even for free), means that this kind of archive/library function also includes functions that are useful for "downstream" handling of the media And its users. The review (and possibly voting) system helps get feedback from viewers, which helps improve the future creative works.

Another interesting type of program is used by libraries and archives, when modernizing records on old media - not just books, photos and pictures, but also, old audio recordings (cylinders, disks, wire, tape), microfiche, film, video tape, etc. These programs handle the cataloging of the original and new media, as well as manage the "'''work flow'''" process of conversion.

For example

The Digital Asset Factory (not certain if open source) http://wiki.bibalex.org/DAFWiki/index.php/Main_Page http://wiki.bibalex.org/DAFWiki/index.php/Key_Features

and Open Collections (is open source) http://www.opencollection.org/index.php?g=about&s=overview http://www.opencollection.org/index.php?g=about&s=features

. --["Tree"][[DateTime(2008-08-27T20:38:00NZ)]].

== Asset View / Clip Window ==
I think it is very important to think about a good way to display the clips / assets / whatever you want to call them. The "big" NLE Systems more or less have the same options:

Graphic View Small (Small Thumbnails) Graphic View Big (Big Thumbnails - SQEdit has the option to shuttle through the clips in this view by clicking and dragging IN the Thumbnail view, maybe the option to playback the clip in its thumbnail view) Simple Display (usually only Clipname) Detailed Display (Clipname & freely configurable Columns (Avid) or fixed set of Columns (FCP) )

In Avid, the uppermost window in the hierarchy is the "Project" Window. This contains Bins. Any kind of Media & Sequences (EDL's) can only be placed in Bins, Bins themselves can be grouped in Folders. Imported Graphics are shown as clips. Audio Only Files have a special icon, as well as Effect Presets, which can also be placed along the other items in the bins.

SQEdit only knows folders but relies much more on it's filtering / options. Therefore you can also switch between Flat and Hierarchical view. In Flatview, all the Clips in the System are shown in one big list - sounds horrible but really is easy to handle because you just type in a few characters on top of the column and only your projects clips are shown, you type some more in the Date Columns and the selection narrows down again. (imagine iTunes like)

Interesting in Avid and SQEdit are the sorting and filtering options. In SQEdit you can type any kind of search term in the top of each column and it will filter out everything that does match - like "*0808" in the Date Column will filter all the clips from August 08. In Avid you can set a "Sifted" view, applying filters to any column like "Show Sifted -> Tracks -> V1A1A2 will only show Clips that have Tracks Video 1 and Audio 1&2 present). In any Program you can Sort by any Column. Most often used: Clipname / TC-Start / Tapename.

In Avid you can select two (or more) Columns and sort by these, like Tapename and TC-Start will sort by Tape and each Tapes items by TC. In Avid you can add custom columns i.e. "Assistant Editors Comments", where the Assistant can type any remark he wants. It's nice if you can set a color label to Clips, which can optionally be displayed in the Timeline too.

(Somebody, Sometime)

== Timeline ==
I think it is really not a priority that the Clips in the timeline have a Thumbnail view, some people like to use one thumbnail image in the beginning of the clip, but nobody i know uses continuous Thumbnails to show a clip. Much more important is to have options to put these or more infos in each clipview in the timeline - mark Clips that moved out of Sync to their audio,  - mark clips that are duplicate - show clipname - show source TC of the clip - show handle lenght (how much more material does a clip have before its in and out point) - mark realtime capable effects / show what clips have to be rendered - mark different resolutions (if lumiera will be able to mix resolutions / formats (DV/HDV/HD) -

(Somebody , Sometime)

== Thumbnail Importance or Trackline information in Trackview. ==
It would be really handy if the user can choose what information they want shown on a track, on a track by track basis. Some suggestions above include both thumbnail And effects information (either overlaid/superimposed, or below each other). But maybe some users just want one Or the other - so why not allow the choice to be made?

The importance of a thumbnail view is increased when the  '''''camera rectangle'''''''''''''''''''''''''''''  (for source clips) is super imposed on the thumbnails - something which I am not sure many other (professional) NL Editors have an option for. This representation is far more visually meaningful for rapid understanding, than the levels curves (which are more meaningful to edit) and sliders. Same usefulness for tracks which get output, but show the  '''''projector rectangles'''''  (or other irregular shapes of masks,etc) of the component inputs.

So the thumbnails in trackview are made as per the composer, instead of the viewer.

Another option for thumbnail view is to show the '''''cropped thumbnail''''''''''''''''''''''''''''', so the '''''camera view takes up the whole thumbnail''''''''''''''''''''''''''''' (or say 90%) of it - so the user gets an idea of how good the current selected area is). And '''''similar for the projector views''''' on the output tracks.

The thumbnails also give a good idea of where scene changes occur within a clip.

With the provision of choice, the issue of "this OR that" in the design brief decision process is removed. The result requires more work, but is more flexible to meet a wider range of users, and their preferences. Gathering information (if user feedback systems are used) on the preferences of users (and those who aren't using it for some reason), will help establish in future, what the most desired system are - something which may or may not be (accurately pre-)determined by the creators.

 . --["Tree"][[DateTime(2008-09-05T11:03:00NZ)]].
== Lumiera - a vision for the future of (Linux) NLE - Inviting more ideas contributions. ==
Thanks for the credits. http://lumiera.org/credits.html

Folks, if you have got any ideas, do please feel free to put them down on this page. I know it says "Brainstorm for the GUI". But the GUI is the interface to how you use "everything" in the NLE (whether you have direct control or not). So until there are pages for Brainstorming on other matters, you can try providing your ideas here. May be an index linking to topics on this page could be placed at the top.

This is "Brainstorming", and no decisions for a "Design Brief or Spec" get made here. There's no guaranty that an idea will eventually get used. This Brainstorming helps provide ideas for a solution/opportunities space from which the developers can derive inspiration. But you can be sure, that what you do not say, will definitely not be heard. Forethought, is a good precaution against the (usually unfortunate) need for hindsight (an experience usually learned in hindsight).

Notice the Project Objectives ( http://lumiera.org/ ) ;

"To  create, as a  community, a non linear video editing and compositing FOSS application for Linux/Unix/Posix Operating Systems, suitable  for professional and quality oriented work, building on common open source video, sound and GUI  toolkits and libraries, providing  flexibility  and a  high degree of configurability  and  full control of all parameters, but at the same time a  smooth workflow  which  scales well to larger and  more complicated  editing  projects."

There is much in this statement that reflects the "open" mindedness of the project team, and the desire to deliver a result that will be excellent at what it does, which will likely exceed what can be done by what is currently generally available. So any ideas on the short comings of current systems, or ideas on new alternatives are very helpful - the sooner you can put them in the better. Do not worry if you are a newbie, or experienced professional, you can help make this program easier to to learn, faster to use, excellent results, more flexible options, ... all those user interface issues.

Cinelerra 4 is now available from Heroine Warrior http://www.heroinewarrior.com/cinelerra.php3

 . --["Tree"][[DateTime(2008-09-05T11:03:00NZ)]].
== A Possible GUI Layout for Lumiera ?? ==
attachment:lumiera20080619-track_insert_split_view_ver6b.jpg

Features ;

Main Window

 * added project name and name of person currently doing the editing. (so somebody else can open another instance on the same PC and nobody gets confused.)
 * moved the startings of a toolbar on the second line, up to the top line, to save space. Though it is likely that the menu (top left) will have a few more options than at present.
 * Tabs for workflow processes.
 * MultiTrack timeline is full height so more tracks can be viewed at once.
Viewer and Assets Panels

 * The multitrack is shown in split view. More than two splits are possible.
 * The tabs above the tracklines, are used to display the various labels, edit points, and insertion points, so that one can jump easily from location to location. Not all points may be assigned to a tab, which means tabs (sets) can be used for the main items being worked for the moment. This is very useful because it allows the swapping of views for front/left and back/right track/time locations. Very useful for inserts, and also for checking the start and end conditions of edits and effects (e.g. scrolling credits).
 * At both ends of the tabline for each split view are arrows for advancing to earlier or later tabs.
 * Top right of the timeline is the "x" for close, and arrow to minimize left, or maximize right for the timeline view.
 * Top left of the timeline view has the magnifying glasses for increasing or decreasing time resolution.
 * Down the left side of the tracks, is a feature called "Track Group Set Selector". This feature is like a "bank switch" for selecting the tracks that are activated and/or viewed (non active tracks are still displayed in the same order, but are shown in very reduced size). This saves mucking around with activation of individual tracks, and reduces the chance of error. Each "Group Set" can be labelled, and more created. An example of a sensible label might be "Wk Tk 1" which would be assigned a pop-up description of "Editing Inserts and transitions on track 1". These have a slider so the additional tabs can be brought into view.
 * Each track has a small box (top left in header) which can be activated to include the track for viewing in the current Track Group Set.
 * The right side of the trackview has a slider so all tracks can be viewed.
 * In between the split views, there are arrows in the divider to shift the divider left or right, so the width can be adjusted.
 * The slider at the bottom, by default adjusts the time in the left view, and advances the right view by the same amount. The right view can be disconnected from the left, for independent time adjustment.
 * The slider can be optionally split to independently control each view.
 * Viewer and resources are beside the track view, so get good height, but do not waste any surplus width.
 * More panels can be added, to show more concurrent views.
 * the panels may be able to be resized (to some extent)
Trackview Timeline Panel

 * The Viewer and Assets panels (and tabs for two more e.g. transitions, effects, if assets become clips), can be displayed in the same space. the 4 tabs multiply the usage of this space by 4. If assets are not needed to be displayed then the space can be used to display something else.
 * The Viewer has a drop down selection for a choice of locations to view. Choices include "Current Position"(the normal default location that would be displayed), start of insert, end of insert, named and numbered label positions, named and numbered edit locations. The position that is displayed may, or may not be immediately related to the current position on the time line, and could be used to check the effect somewhere else on the video while editing at the current location on the timeline (e.g. view midway through a slow pan, to check that adjustments at ends do not get "off subject" midway - bad example but simple).
 * The Viewer has a button for Shape definition which can do rectangles, ovals, irregular lines, outline search, etc. The shape that is drawn can then be applied to Camera, Projector, or Mask which each have buttons for their own setting. This would be a good location to have the Motion (tracker) button.
Additional Features

 * The viewer and Asset Panels can be placed above the tracks as per the image at the top of this page, but the idea of using tabs in the panels to gte better space usage would be good to retain.
 * Similar reasoning for retaining use of tabs in the trackview timeline.
 * When doing inserts, the start or ends point may be fixed and the other end left floating, or both floating. The ends could have a grey or transparent zone to show the time-stretches that a transition can extend out to - to be used to check that the insert will be dropped with both ends within acceptable limits. The viewer panels can be set so one displays the start of the insert, while the other displays the end.
 * Track insert mode can handle the movement of more than one track(clip) at once. It can permit the movement of a "grouped connected set of tracks" at once, either along their own tracks, or vertically re-allocated to other (free or used) tracks and moved along them.
 * When any grouping is made (of anything), then it may be handy to be able to save it for re-use in other similar projects.
  . --["Tree"][[DateTime(2008-09-08T21:31:00NZ)]] .
== Achieve similar function as a distributed GUI client/server ==
Some folks have expressed a desire for a client server functionality in Lumiera. It sounds like this will not be built in to the program. However, the objective of allowing low spec machines to do edits, and have the rendering done on more powerful (remote) machines, can be achieved by other means. Although it may not be possible to use Thin Clients, it is still possible to use low spec PCs.

This is done by having Lumiera run on the low spec PC, but instead it''''' uses low resolution files'''''. The edits all get done, and the edit list (and other changes) get sent back to another more powerful PC which can load them , and do rendering, or just add them into the main project. The low resolution files, can be generating at the same time as capturing the high resolution files (easy with firewire)(not difficult anyway), or can be generated when required/requested.

 . --["Tree"][[DateTime(2008-09-09T11:28:00NZ)]] .
== Distributed Editing Features - safety (and then may be security) ==
Just as media have "players" and proprietary software like spreadsheets have "readers", it might be useful to have the ability for users to issue cutback versions of Lumiera, or at least issue a set of rules associated with particular video strips for authority to edit (or not - just view). This would allow, say, a video strip to be made available for editing, and people can do their own edits, and upload them for sharing and comparing, competitions.

 . --["Tree"][[DateTime(2008-09-09T11:36:00NZ)]] .
== Associating Users with rights to Editing Features - security and Editing Authorization level ==
CMS website system and some document managements systems, allow different levels of access to editing features. This ensures that people do not get to make mistakes with data.

The edit lists, can be treated this way. Maybe the video can be treated this way but might be more difficult. For the video files, it might be done by data within the file, but probably easier to do using an index system.

It might not be totally secure, in that it prevents access of any kind. But it would certainly help a user to be reminded if they accidentally start editing something that somebody else is working on. .

 . --["Tree"][[DateTime(2008-09-09T11:42:00NZ)]] .
== 3D scene capture in video - future proofing Lumiera ==
At present there is not much available in the way of 3D editors. Mainly because there is not much 3d projectors. 3D is currently usually done by making a 2D screen appear to show 3D objects. But the days will come when projectors will use systems like holography to make 3D shows which are viewable from many angles.

There is currently a number of programs which can use still images from several angles as input, and generate a 3D representation of the content. It's just a step in computing power, and some programming, to step this feature up to use video (which can also time average the resolution of the estimated object shapes). I

n order to generate the 3D representations, the camera positions, and also preferably including the camera optical characteristics, need to be known (although one or two systems have the intelligence to infer the positions). The camera info gets matched with the camera track.

The viewer could be like cube (if the cameras were orthogonally mounted), with a projection of each camera on the respective face of the cube. Inside the cube would be the generated scene. If the cameras have some other spacial relationship (than orthogonal) then they could be projected onto the faces of sides of an appropriate 3D shape, again with the generated scene inside it.

The shapes can be rotated to see what the scene looks like from different angles - a useful 3D effect even when making 2D movies - can generate an instantaneous camera pan/swing. Although this is all too far out in the future, it could be allowed for now by considering how the information would handled in future, making it much easier to adapt the "engine" if/when the time comes.

 . --["Tree"][[DateTime(2008-09-09T11:57:00NZ)]] .
== Getting more "Grunt" from the GUI and Proc Layer ==
The proc layer could be set up to be sitting in the background doing processing for "any" sources of "requestors". Requestors could be batch jobs, renders as needed, requests from other PCs on the network. And if vacant processing power is available, could even be '''''doing anticipative/prefetch type tasks'''''. anticipative/prefetch type tasks might include tasks like ;

 * thumbnails of effects that are likely to be requested at this stage.
 * render at typically requested output formats
 * render at best guessed '''''camera crop''''''''''''''''''''''''''''' (maybe including '''''subject tracker with zoom''''').
The proc layer might be able to be on a different PC. The frontend request, gets managed by the backend and the backend could be making decisions about which PC will get used to provide the proc layer services for each request - multi-processing (renderfarm for everything). Now whether these functions can be built into Lumiera or not, it might be possible to have them in effect by using virtual servers that can run on multiple boxes, and use virtual boxes on the server to run multiple GUI frontends. The advantage of this approach is that Lumiera project does not have to deal with the management of the hardware, and proven systems are used for that task. Additional benefit of virtual server is that is is very easy to add/remove hardware/disks in the system without having to shut it down. This means that for large render jobs, the hardware can be brought in for a few days (hired in or ravage the office PCs for the weekend), connected up used, and then removed. Repairs are no longer a critical issue.

The virtual boxes have similar advantages for hardware maintenance, especially as they would be 'floating" on the virtual server.

Tools e.g. http://oscar.openclustergroup.org/easy installer for beowulf clusters.

. --["Tree"][[DateTime(2008-09-15T14:33:00NZ)]] .

----

== Protocol for Lighting (and camera) Control - plugin like EDL and Midi interfacing,and firewire ==
There is a protocol for lighting control called DMX512. This can control lights on/of, brightness, lighting wheel rotations, filters, and pan tilt for spot light gimbals. As far as "light" goes, the lighting systems "send" light, but also the camera systems "receive" light. So the lighting control system can be used for controlling camera mounts, and for coordinating lighting and camera combined sequences.

There is also Midi Show Control (MSC).

Because the DMX512 lighting protocol controls electronic devices, it could also be used for triggering and control of other live lighting effects.

The interface would enable Lumiera to be told ;

 1. what is going on, and the information can be recorded, so the sequence can be used during editing to decide which tracks to use. and/or
 1. commands for what to record (and how - e.g. which direction) , by what cameras on which tracks. and/or
 1. allow Lumiera to act as controller to coordinate the whole sequence - either preprogrammed, or on cue as per manual input from Lumiera actions.
resources; DMX512

 * http://en.wikipedia.org/wiki/DMX512-A
 * http://www.usitt.org/standards/DMX512.html
 * http://www.lighting-association.com/links/dmx-faq.htm
 * http://www.dmx512.com/
 * http://www.dmx512-online.com/
 * DMX4Linux a DMX512 driver - http://llg.cubic.org/dmx4linux/coding.html
 * and "Q Light Controller" - full featured control DMX512 - http://sourceforge.net/projects/qlc/  http://qlc.sourceforge.net/index.php?doc=Features
Midi Show Control

 * http://en.wikipedia.org/wiki/MIDI_Show_Control
 * http://en.wikipedia.org/wiki/Musical_Instrument_Digital_Interface   ('''''MSC and Midi over Ethernet !!! and RTP''''')
 * http://www.midi.org/about-midi/specinfo.shtml
 * http://www.asus.net.pl/index.php?wiki=MIDI
 * VControl from Vman has linux MSC program free unregistered version that runs for one hour, then you need to restart it. A free registration key, gets unlimited time and runs two channels  http://www.vman.cc/epages/61623692.sf/en_US/?ObjectPath=/Shops/61623692/Categories/Downloads/V-Control_Downloads/Free_V-Control_Key
 * QLab version for MacOS (May be this could get ported) free version http://figure53.com/qlab/download/
 * Midi Show Control Specification - excellent range of devices and control - http://www.richmondsounddesign.com/txt/midi-show-control-specification.txt
__'''''Note for making other real world interfaces - plugins'''''__ There are several other theatrical and film performance control systems, and other real world device control systems (e.g. http://www.epanorama.net/links/automation.html#home ). When designing an interface with Lumiera (for any of these), then it would be handy to make the plugin spec available, so that people can write the plugins for the other device control systems. This would include all the forms of output signal from Lumiera available for controlling devices, and all the functions in lumiera that can be controlled by external devices.

Lumiera has some features in common with the following standard hardware items, which can be controlled by standard signals on DMX512 and MSC ;

 * Video Recorder/Player (one for each track)
 * Video Switch (channel for each track)
 * Video Projector (one for each track)
So this makes it possible for'''''Lumiera to be designed to appear as a Device on MSC and DMX512'''''(and other) control systems (networks).

A very exciting possibility arises when the ability to send and receive'''''MSC and Midi over Ethernet !!! and RTP''''''''''''''''''''''''''''', because that then'''''permits Lumiera (as a Device)'''''''''''''''''''''''''''''and all the lighting systems to be'''''remotely controlled'''''.  This does not prevent Lumiera from being remotely controlled by common PC remote control methods available to Linux.

. --["Tree"][[DateTime(2008-09-17T11:57:00NZ)]] .

== Open Sound Control - plugin ==
 . Open Sound Control (OSC) is a protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology. Bringing the benefits of modern networking technology to the world of electronic musical instruments, OSC's advantages include interoperability, accuracy, flexibility, and enhanced organization and documentation.
This simple yet powerful protocol provides everything needed for real-time control of sound and other media processing while remaining flexible and easy to implement.

Features:

 * Open-ended, dynamic, URL-style symbolic naming scheme
 * Symbolic and high-resolution numeric  argument data
 * Pattern matching language to specify multiple recipients of a single message
 * High resolution time tags
 * "Bundles" of messages whose effects must occur simultaneously
 * Query system to dynamically find out the capabilities of an OSC  server and get documentation
 There are dozens of implementations of OSC, including real-time sound and media processing environments, web interactivity tools, software synthesizers, a large variety programming languages, and hardware devices for sensor measurement. OSC has achieved wide use in fields including computer-based new interfaces for musical expression, wide-area and local-area '''''networked''''' distributed music systems, inter-process communication, and even within a single application.
http://opensoundcontrol.org/

. --["Tree"][[DateTime(2008-09-25T18:09:00NZ)]].

----
== Free Open Source PreProduction Production Program - CeltX ==
The CeltX FOSS project has screenplay, text editor, storyboard, schedule, web service, and type set. These can all be correlated to scenes, clips, labels in Lumiera by using labels or metatags. The code could possibly be used as a backend, while the front end Gui is styled to match Lumiera. The front end could show each of these features as a tap, in the main track view (which replaces the whole view of tracks, when the tab is clicked on). It might be possible to have a scrolling commentary, scrolling script, scrolling effects inventory, that can show in a box/window on the side of a track or composer view as it plays. It might be possible to scroll play the script, read it and record the rough draft draft sound track, time could be left for other events as real time, and crude sound effects can be used - this would help to estimate how long the scene is going to be, without even any video needing to be shot.

 . see http://www.celtx.com/screens.html
As an integral part of the kit (or program), this would facilitate on-site rewrites of the script, or overnight adaptions, with estimates of time added or removed from job.

b) A speech to text unit could collect impromptu improvisations and add it to the text, saving on time to transcribe new notes.

c) Text to speech could generate very rough estimates of sound tracks - boring and soon replaced, but a start that saves the time in the first instance of having to generate voice content - even before actors have been hired.

d) The text information for scripts could be made transferable into a subtitle editing system, where all that would remain, is to synchronize i he text with the video (saving text re-enter).The text editor would be there, if there were any deviations between the actual script and what got spoken. For exactness, it would be possible (if one wanted), to update the scripts, to include that actual words said in the final cut (plus notes, say on expression), which might be handy for historical purposes.

e) Also need ability to make pre-production and on-site notes for precautions of "continuity" of scene (i.e. watch those watches).

The CeltX program has a forum. A few comments there such as the one below, talk about the need to have a timeline function. The time line function would allow comments and information on various aspects of the project to be made, and shown against time. This ties in with some of the Track and Timeline concepts mentioned elsewhere in this brainstorm. If CeltX is contacted, then there might be some possibility to make metadata/labels in the script (and effects notes) match up with metadata/labels in the video.

The script from CeltX could also be exported, ready for subtitle editing, and synchronization with the video (using the metadata/labels).

see http://forums.celtx.com/viewtopic.php?t=7310&highlight=video

 . --["Tree"][[DateTime(2008-07-18T22:27:00NZ)]] .
== Open Source "Free Film Project" could be part of Production Tool Kit ==
Free Film Project - complete movie studio - GNU Project - Free Software Foundation (FSF). This project is in the early stages, but has a few programs that might be handy alongside/inside Lumiera.

The FFP has a graphics filter; OnCue, a lighting control program; and StoryBoard Model Scripting Tool and Scriptwriter, both scripting utilities.

Current efforts concentrate on distributed computing, video editing, and animation rendering, although coding continues on all modules.

There is an opportunity for Lumiera to fill the gaps in this FFP project and to work together (even if only just loosely to liaise on data compatibility).

 . http://www.gnu.org/software/ffp/ffp.html http://directory.fsf.org/project/ffp/
 . --["Tree"][[DateTime(2008-07-31T21:51:00NZ)]] .
== Open Source "Advene Project" - annotator and hypervideo programme maker ==
Advene (Annotate Digital Video, Exchange on the NEt) is an ongoing project that aims at providing a model and a format to share annotations about digital video documents (movies, courses, conferences...), as well as tools to edit and visualize the hypervideos generated from both the annotations and the audiovisual documents. Teachers, moviegoers, etc. can use them to exchange multimedia comments and analyses about video documents. The project also aims at studying the way that communities of users (teachers, moviegoers, students...) will use these self-publishing tools to share their audiovisual "readings", and to envision new editing and viewing interfaces for interactive comment and analysis of audiovisual content. Features

 * Annotation of video documents (from DVDs or digital files)
 * Import of annotations from other sources : ELAN, SRT files, transcriptions with timestamps inserted, etc.
 * Display of annotations' content (or anything derived) as SVG caption on the video
 * Multiple ad-hoc views of annotations : timeline, treeview, transcription, etc.
 * Embedded webserver with dynamic generation of XHTML documents using data taken from the annotations
 * Ability to dynamically control the video player based on the annotations
 * Ability to define dynamic views (for instance Display text as captions and propose to navigate between shots)
 * Annotations and views are stored in packages that can be saved, shared, stored on a server, etc.
h t t p :// liris.cnrs.fr / advene   (remove spaces)  and  https://gna.org/projects/advene/

 . --["Tree"][[DateTime(2008-07-31T21:51:00NZ)]] .
== "Annodex" project ==
The Annodex project has code, libraries, plugins for creating and managing several forms of metadata for multimedia to make searches more efficient in house and on the world wide web.

http://annodex.net/taxonomy_menu/6/33

 . --["Tree"][[DateTime(2008-09-30T23:18:00NZ)]] .
== Render Engines ==
 * Piave is the render engine behind KDenLive  http://modesto.sourceforge.net/piave/   .   Screenshot  at http://modesto.sourceforge.net/piave/screen-01_thumb.png
 * Snice is in the early stages of development http://sourceforge.net/projects/snice/#item3rd-1  .  Screenshot of node diagram at http://sourceforge.net/dbimage.php?id=27650
These projects may contain some useful code, information to help make compatible plugin management, coordinate with to build backend engines, that may have modules/compents/raw code that can be swapped/interposed between the various projects. . --["Tree"][[DateTime(2008-10-01T12:12:00NZ)]] .

----
 . CategoryCategory
I have two suggestions: 1.) Make the GUI easy to use and follow an already existing paradigm (i.e., use the timeline paradigm that is found in virtually all NLE apps), don't clutter the GUI with a whole bunch of buttons, and use Apple's Human Interface Guidelines found here: http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/chapter_1_section_1.html

As well, please, please, please, please, do not use the black or dark gray background or dark blue with light gray or white text - that is sooo hard to read and looks absolutely horrendous! Just use the default GUI components/widgets that are provided (e.g., GNOME's standard UI features) where you can and only create custom components when you need to (i.e., they don't exist - like the timeline component). Leave the default colors alone for the GUI!

2.) Start off simple. Plan on releasing just the basics and then build on top of that. Don't try and take on Final Cut Pro or even Premiere for that matter. Get the following features working as a first release: - timeline working with drag/drop, razor, cut/paste, snap to edge/end/beginning - undo/redo - one video track, one audio track, one titles track

Call that release 0.1 which should be more than plenty. And release it as a DEB file so that users can simply install and not have to recompile half their operating system.

- Arron

----
== Problem with GUI edit mode on this page ==
When saved the new paragraph markers get lost, and so it all becomes one big paragraph. The only way to fix it, is to go back and re-insert the new paragraphs, which have a better chance of being remembered.

The new paragraph markers get lost when the page is saved. So all the lines get bunched into one big paragraph.

When text is set to bold and/or itallic, the spaces left and right of the changed text get lost.

Both of these problems mean that you have to edit twice. Once for text entry, second for paragraph and word layout.

 . --["Tree"][[DateTime(2008-09-11T14:58:00NZ)]] .
----
== 3D Application of Lumiera in future - general discussion ==
'''''3D modelling '''''''''''''''''''''''''''''and  '''''virtual reality  '''''are becoming increasingly important tools for movie making, and visual effects. Although these features do not fit the requirements of a "clip editor", the ability to interface with them is handy. A program that includes them closely (integrated/styled) within it's UI (even though they may be separate programs) will probably be even more promising.

These 3D effects are rendered then shown in 2D representation for the video media. An interesting consideration to think about for the future, is when 3D representation will be able to be viewed in "3"D. How this will be done is yet to be decided, but it will however require the playing of "tracks". So the application of manipulations to tracks could be done allowing for the possibility of being applied to 3D visualizations (e.g. a "wipe" transition sweeping through 3D scenes). Three types of '''''3D visual representation '''''might be ;

 1. 3 orthogonal camera views (X,Y,Z), or
 1. 2 horizontally separated cameras to provide stereoscopic view
 1. 1 holographic panorama (which would need to be converted for the persons to understand).
In each method of 3D representation, the tracks that make up the 3D information, can be identified as a''''' "3D set"''''''''''''''''''''''''''''', so they can be manipulated together. "Simultaneous manipulation of groups of tracks" is a feature that may be being built into Lumiera anyway, so this would just be a special reason for using the feature with tweaks to make the job easier. ''''' '''''

'''''Transitions '''''in the current 2D, can be made available in 3D by treating them as being "on axis" to the viewer's direction. This would then allow coordinate transformations to re-orientate them in 3D. Then there are possibilities for completely new real 3D transition effects, probably not even imagined yet (e.g. rubic cube transition by rotating blocks and changing colors/shades).

The  '''''scripting systems'''''  used in 3D Cad, 3D Modelling, Virtual Reality, Gaming, 3D Dynamics could be useful to allow for - not have to have - but just be able to use when needed (later).

For example ;

 . Lisp scripting language as used in Autodesk's AutoCAD http://usa.autodesk.com/adsk/servlet/usearch/results?la=en&siteID=123112&catID=123155&id=2088334&nh=10&qt=lisp&rq=0&oq=forth&col=wacjprd&col=usuppprd .
 . .
 . and Lua (interpreter and compiler versions available) scripting language (chosen for Lumiera) which is used in games.
 . http://www.lua.org/about.html
--["Tree"][[DateTime(2008-10-20T17:38:00NZ)]] .

----
== Note for script editors and effects management ==
Because the Lua script language is available as an interpreter and as a '''''compiler''''', then it would be possible to convert re-usable scripts to compiled format to speed up rendering.

Also within a project, once the "sub"-script for a clip/strip/video has been finalized, or is not likely to be edited again over then next several draft renderings, then it might be possible to "commit" the scripts to be compiled for use in the project "until any of them get edited again". This method enables draft rendering to be faster.

--["Tree"][[DateTime(2008-10-20T20:00:00NZ)]] .

----
== Sound triggered by events, states/conditions and actions ==
The UI can have the usual triggering of sounds for actions. The sound sets can be made by the users; music, different spoken languages, different themes.

The sound feedback (when voiced or recognized) allows the user to move more swiftly through the program/windows, as they no longer need to stay "looking" at a windo view to confirm a result, because they can move on to the next action and "listen" for confirmation of successful completion.

There could be an option for the user to choose to be prompted with tips (e.g starting tips), which could also be triggered by actions followed by a delay of inaction. The user could select the delay before a prompting. When set up this way, the sound system could be used as a voiced guide/teacher.

--["Tree"][[DateTime(2008-11-14T18:17:00NZ)]] .

----
== Shrink video button ==
I like the idea from Adobe After Effects, where you can shrink your films and work with the lower resolutions to improve the speed of editing, very much. Almost realtime previewing, working on old, slow machines... would be the result for Lumiera. It would be very great, when Lumiera could shrink all the original videos of a project with only a button and in this function you could choose the quality you want to work with. the quality should be during the cutting variable. So that in some scenes where you need more details, you choos the bigger resolution and so on.

-- Wikiants[[DateTime(2008-12-14T16:45:00NZ)]] -- http://en.wikiants.org/Lumiera

----
== a note on "concurrency" and EDLs ==
1) EDL = edit decision list.

edit = process which is not yet completed

decision = many options for alternative solutions

list = (linear/stepwise) arrangement of process (but method of use may be "non-linear", or "random access" - with parallel/concurrent options, and tree/branch/threads)

EDLs are not just about recording steps, and making re-usable code, but are also able to be used for analyzing alternative methods, and effects of order of doing things.

EDLs can be used sequentially one after the other in an automated process (macro), but this process may also be enabled with additional intelligence - either by automated decision making, or by prompting the user for decisions (maybe with suggested/thumbnail options).

2) EDL is one of terms used in video editing, so keeping the term will maintain familiarity for some of the seasoned users. Even if it is not the term used in Lumiera (by default) it could still be used in an explanation of what ever term is used.

2) It might be possible for Lumiera to have '''''user chosen terms/phrases''''', so the user can choose the word/phrase for terms that they are most comfortable with (would work for any language).

3) if Lumiera is''''' able to display the view of more than one track''''' at once, and/or be able to display more than one EDL option for the same (or many) track at once, then this makes it very easy to do "side-by-side" comparisons of strips. These act like thumbnails (even if they are the result of strenuous manual effort by the film editing crew), which allow effective "live" analysis, and choosing "best bits" of each. EDLs may have been created for similar strips, but relate to managing different aspects of the video manipulation - these EDLs could "ADDed" together (a bit like image overlays). Concurrent views, would allow the automatic generation of combination of results, and quick selection of the options that are within the desired range.

AA) so the power of EDL management is increased beyond being able to "replay/re-use", by being able to ;

i)'''"associate" similar EDLs as "groups/options" sets''' that can be used as "range of choices" in future situations. The user could associate comments with the "group/choice" set, such as "we found these options to all be good, but think that A+B are best for when .., while D and E are best for when some else .." .

ii) include''' allowance for decision processes''', in the application of combinations of EDL sets. In the first instance this would enable the prompting of the user for a decision, with some tips on how to make a good decision. But later could include methods for programed decision making.

BB) The  '''ability to show multiple views'''  (or different tracks, or the same tracks with different EDLs applied, may be achieved by allows more than one instance of the viewer engine to run - I don't know if this is the best option, but for those who would find this a great benefit, then any resulting noticeable performance drops may be tolerable.

An __additional note on EDLs__.

If a user has the raw video data (obtained on media, or by fast network), and it is the same "common data" as used/refered to by all members of a team,

then they only need to transfer their EDLs, to let the others know what their updated work is.

So creational/artistic people like to "get away" to an environment that relaxes/calms/inspires them, but such an environment may not have broadband available. EDLs are far easier to send over dialup, or even snail mail on cd/dvd than trying to send a full rendered project down the line.

The number of people needing this may be few, but they are also likely to be some of the intensive users. it would be important to have ease of transferring/communicating EDLs (and similarly used files) in-to an out-of a local project (which may be as large as files being shared on a local server) - this may include not just the "transfer", but also the (more integrated) automatic updating, and rendering of the updates on the local system project, when EDLs are received (or at some other determined convenient time).

 . --["Tree"][[DateTime(2008-12-15T13:42:00NZ)]]
----

== Lumiera project promotion on the Internet ==
The web pages currently do not have much use of metatags such as title, description, keywords (which can also be phrases), author, etc. These get used by search engines to catalog the website, and fine-tune searches. Use keywords that are what people would use to find your site (a) when they know what to look for to find toy, (b) when they are looking for this genre, but have no idea "you" exist (e.g. video editor, multitrack editor, nle, foss, open source, linux, linux video, cinelerra)(programs and tools used to make the project).

Set up an RSS news system and promote getting connected to it. e.g. use it to send articles to linux and video blogs, magazines, ezines, video component and product vendors, etc.

Some links to websites where Lumiera has already been mentioned, are at http://www.pipapo.org/pipawiki/Lumiera/Links

Attracting visitors will build interest, create potential users, build the development team, cause results that haven't been anticipated (for the better).

 . --["Tree"][[DateTime(2008-09-05T21:33:00NZ)]] .
== Lumiera project website promotion on the Internet ==
The Lumiera web sites This and lumiera.org) can be tweaked to show up in the search engines better, on related topics. This helps the project to get exposure to many more people. Currently the web pages are have not used metatags to any large extent, and there is room to significantly increase the effectiveness of use of these metatags. The following are some suggestions/examples for use of metatags in the web page headers ;

__Title__

 * "Lumiera - a re-write of Cinelerra" "Lumiera - multitrack video editor for linux"
 * "Lumiera a new nonlinear multitrack video editor cousin to Cinelerra"
 * "Cinelerra nonlinear video editor offshoot becomes Lumiera"
__Description__ (Can usually get about 20 to 30 words in this)

 * "Lumiera is new project to rewrite the Cinelerra non linear video editor, using open source resources."
 * "Lumiera - Open Source non linera multitrack video editor for linux based on a rewrite of Cinelerra, and many new features."
 * "Lumiera - non-linear multitrack video editor FOSS project to redesign Cinelerra with additional features and improved GUI and usability"
__Keywords__ (phrases) (can sometimes go up to 200 characters or more , but must be words used on the page)

lumiera, cinelerra, nle, multitrack, professional, video editor, foss, open source, gpl, lgpl, workflow, gui, tools, plugins, download, nonlinear editor, video, how to, c++, programming, developer, project, widget, usability, camera, projector, effects, transition, feedback, input, linux, latest news, update, free, freeware, license

__Notes__;

1) Some search engines will automatically refuse to catalog sites that contain statements such as "(website/webpage currently) under construction" (even on just one page). So it is a very good idea to not use such phrases in our text. It is far better to say things like, "This is a new and exciting project, which will be growing. Please keep coming back to see the latest developments."

2) Put Title, Description, and Keywords on each page - taylored to match the content of each page.

3) Lumiera is coming tops for "Lumiera", but that is only ever any good for folks who already know what the project is called. To get found by people who know nothing about the project then try to use words that people doing searches on "this kind of topic" would use - e.g. "nonlinear video editor" AND "linux" . Try to get to the top of these searches ;

a][http://www.google.co.nz/search?hl=en&as_q=+AND+linux&as_epq=nonlinear+video+editor+&as_oq=&as_eq=&num=100&lr=&as_filetype=&ft=i&as_sitesearch=&as_qdr=all&as_rights=&as_occt=any&cr=&as_nlo=&as_nhi=&safe=images google search for "nonlinear video editor" AND "linux"].

b][http://www.google.co.nz/search?hl=en&as_q=+AND+linux&as_epq=video+editor+&as_oq=&as_eq=&num=100&lr=&as_filetype=&ft=i&as_sitesearch=&as_qdr=all&as_rights=&as_occt=any&cr=&as_nlo=&as_nhi=&safe=images google search for "video editor" AND "linux"].

4) Consider Joomla content management system (FOSS) for web site design. Has templates, menu management, handles multiple authors, and much much more. http://www.joomla.org/

 . --["Tree"][[DateTime(2008-09-11T14:25:00NZ)]] .
== solicitations and invitations Team Building ==
The website (here and at http://www.lumiera.org could invite people to join the project, and show the way to join in in. Use the website to build teams, and attract contributors. There is probably much that can be done, that is not core production, but would help. Some of the work done by these helpers may never be used,  but if they understand this they may still want to help. e.g There is only going to be one logo, but look how many folks are prepared to help.

example areas of contribution might be;

 * buttons, icons - large and small sets
 * EDL conversion plugins (probably just text string editors) -  to import (and export to) from Cinelera (and maybe other editors).
 * plugin designers - once the interfacing system is decided - but some may be willing to start design now, and alter the plugin when the interface gets finalised.
 * designers of "plugin designer" - e.g. might use frontends for imagemagic, gimp, etc
 * help documentation (initially just describing general concepts, but later gets specific, and maybe need frequent rewrites as methods get changed).
 * project publicising - people interested in working on the website, generating RSS news feeds, webmasters of other sites interested in receiving updates, commenters on forums, etc.
The following webpage is a good example, but there is no direct link to any location to actually join in. All promotional material could include a link to the joining methods (join a team, contribute some sort of code, join a mailing list, fill in a survey, join a group for prospective users). A whole forum could be set up for prospective users - spinoffs might include brainstorming on many topics, "help documents" get generated before the code because users have described how they want to be able to use the features - the help documents may get radically altered after feature implementation.

For Example ; an extract from http://www.pipapo.org/pipawiki/Lumiera/ How to participate

First, you should join the Lumiera Mailing List, browse this wiki, hang out on IRC (#lumiera at freenode.net). We started our first design drafts here on the wiki, short lived communication is done on IRC and partially per personal email. We have more formal developer meetings once every month; you may want to skim through the protocols of past meetings. Long lived decisions are documented as design proposals in this wiki. Final decisions and detailed technical documentation are added (currently) to a TiddlyWiki inside the git repository. (You can browse a snapshot of this design TiddlyWiki online here)

Everyone works on his own git, merges with anyone else, at times we decide to accumulate work into a master git. I'll (cehteh) provide git mirroring for people who don't have persistent internet connectivity. People may also decide to mirror at http://repo.or.cz.

 . --["Tree"][[DateTime(2008-12-27T13:25:00NZ)]] .
----
== Video Analysis features ==
There can be features which analyse the video but do nothing to the video/EDL, and maybe prompt the user to do something to improve the situation, or advise on "what not to do" to avoid making things worse. Analyses might include ;

 * a) white balance assessment and uniformity
 * b) brightness
 * c) eye level position detection (especially at transitions)
 * d) times of rapid motion (that may effect quality when compressed - may include information on rate of degradation verses compression)
 * e) shadows - detect amount of detail in shaddows (some video cameras and compression methods delete detail in shaddows, which makes it difficult to brighten the shaddows after the video has been captured).
 * f) noise, speckles
 * g) blur / focus Prompted actions might include ; a) "normalise" within selected or auto identified zones, entire track, across group of tracks.  b) Mark with quality assessment metatags to help with clip selection process later on.
--["Tree"][[DateTime(2008-12-29T11:11:00NZ)]] .

----
== Matroska media container ==
==== About Matroska ====
Matroska is an extensible open standard Audio/Video container. Matroska is usually found as .mkv files (matroska video) and .mka files (matroska audio).

Matroska is an open standards project. This means for personal use it is absolutely free to use and that the technical specifications describing the bitstream are open to everybody, even to companies that would like to support it in their products. The source code of the libraries developed by the Matroska Development Team is licensed under GNU L-GPL. In addition to that, there are also free parsing and playback libraries available under the BSD license, for commercial software adaption.

Matroska is NOT a video or audio "compression format" (video codec). Matroska IS an "envelope" for which there can be many audio, video and subtitles streams, allowing the user to store a complete movie or CD in a single file.

Matroska is designed with the future in mind. It incorporates features you would expect from a modern container format, like:

 * Fast seeking in the file
 * High error recovery
 * Chapter entries
 * Selectable subtitle streams
 * Selectable audio streams
 * Modularly Extendable
 * Streamable over internet (HTTP and RTP audio & video streams)
 * Menus (like DVDs have)
http://www.matroska.org/

http://en.wikipedia.org/wiki/Matroska

http://www.bunkus.org/videotools/mkvtoolnix/

http://www.free-codecs.com/download/Matroska_Pack.htm

==== Use of Matroska in Lumiera ====
 * an already existing method for handling (some) metadata in association with the clips.
 * the system is extensible and in further development, so has the facility to be expanded to increased needs of Lumiera such as much more detailed information about clips, complete editing history, and new media types (3D video, media for other senses).
 * development of this project takes place even without the Lumiera team needing to work directly on it, so improvements made with the Matroska project also apply to Lumiera.
 * Liaison with the Matroska team could see suggestions made by Lumiera team get implemented in a standardised system, which leads to and maintains compatability with other programs that use Matroska.
 * Matroska would make a good "optional extra" for Lumiera.
Matroska is an English word derived from the Russian word "matryoshka" (Russian: матрёшка, IPA: [mɐˈtrʲoʂkə]), which means "nesting doll" (the common Russian egg-shaped doll within a doll).
 * Includes features for including DVD menuing system within the "envelope".
 * possibly many more uses - see the weblinks above.
--["Tree"][[DateTime(2009-01-03T09:33:00NZ)]] .

==== Use of Lumiera as a multichannel player theatre ====
Lumiera can handle multiple tracks for editing and rendering. It is a small additional step to make it able to replay the tracks, more than one at a time.
This would create the seldom available (unique?) feature of being a multi-screen theatre performance.
A simple output administration GUI would be needed. Outputs of the tracks would be coordinated/synchronised, and output options might include ;
 * assigning output to multiple windows on the one PC
 * assigning output to multiple monitors on the one PC
 * assigning output to multiple PCs on a network, and the respective track gets played by a player on each PC.
 * assigning output to multiple PCs on a network, and the respective track viewer window on the Lumiera PC gets played by a remote desktop on each PC.
 * other possibilities including analogue video distribution.
The GUI for the player mode could also be made available as a cut down version/plugin for lumiera, for distribution with video that is to be played in multitrack mode, so the end users/viewers do not have to be seasoned Lumiera users - just to watch the video.
It would be handy to allow any selected track (say track 1 by default) to be used by a conventional player, in the case when the Lumiera multitrack viewer/player is not available.

--["Tree"][[DateTime(2009-01-15T10:54:00NZ)]] .
----
== Optimisation of visual realestate in GUI as at 19/06/08 ==
The current GUI shows an area for resource selection, at the same time as a viewer and tracks.
If the probability of needing to see the viewer at the same time as selecting a resource is low, or if the probabilty of needing to see the resource selctor while concentrating on use of the viewer is low, then it would be worth while considering devoting desktop space to the task more immediately at hand (providing not to many clicks are required to regain the required view space).
ie the whole top are could be used to display more resources when resources are to be chosen (and no viewer is shown). And conversely, when a viewer is shown, the resources seletor can be reduced to a tab, and possibly more viewer windows can be shown (e.g. start and end of effect strip, camera view and projector view, before and after effect application view, views of several tracks, magnified/close-up view of current edit point/s and/or keypoint adjustment sets).

Currently the option to minimise each area is available. This allows the customisation of the view by the user. But this requires the resetting of the view each time the user "switches mode of use" between  resource selection and view. Tabs are handy because they are a one-click method of changing modes while retaining previously set view layouts. Tabs also allow more than one layout option for each mode of use, and view topics.

--["Tree"][[DateTime(2009-01-31T00:30:00NZ)]] .


== Improving GUI's clarity as at 19/06/08 ==
1) The task areas can be better delineated by using small radius corners.

2) The boundaries are more enhanced when 3d shading effect is used on the boundary lines (e.g. as if lighting was from top left).

3) There can be a small area between boundaries ,maybe of a slightly lighter/darker shade, which helps visually separate the areas.

4) Conventionally text for selected tabs and menu items is brighter rather than dimmer, relative to unselected tabs and menu items.

5) The timeline scroll is a percentage motion. To the left of the scroller, there could be placed a widget of a thumbwheel (edge-on) which can be dragged or clicked to move linearly. It could have a high and low ratio speed toggled by an icon to the left of it. Clicking or dragging it could be accompanied by a sound of "click"ing which would help indicate the speed.

--["Tree"][[DateTime(2009-01-31T11:03:00NZ)]] .


----
== feature to create a video from the desktop space - e.g. for a tutorial or demo ==
This could use any/some of the desktop screen session grabbers, along with recording the user's spoken commentary, or ffmpeg's X11 grab function.
The feature could be implemented directly from Lumiera's menu - a bit like recording a macro, except the screen is recorded.
The file is then able to be touched up, clipped, edited, and mixed (say, background music added, and intro and credit rolls) using Lumiera.
It could be saved for in-house instructional use, shared at a Lumiera hosting site, or made available on Youtube and others.
If the tutorials were able to be stored at a Lumiera site, then they could be selected and downloaded by users (possibly from Lumiera itself as needed - e.g. "click here for more help").
The videos can be viewed as separate items, but it adds usefulness to be able to view them from context sensitive help as an additional option.

This feature could be expanded in future to enable the creation of a tutorial video for any program that is being run on the user's desktop (or remote desktop, or web application).
Lumiera would then become a useful tool for instructors, software educators, sales use, '''especially if it can incorporate slide shows, presentations and extracts from them'''.
--["Tree"][[DateTime(2009-01-31T12:43:00NZ)]] .

== Problem with MoinMoin text editor ==
Note - the text editor in MoinMoin is preventing text which contains "x-ing" (without the dash) in it, from loading. So words like "mix-ing" will not allow the text to be saved (ie the whole job! - so pleased it was copy and pasting from text editor.). A safer way to prevent "x-ing" from being used might be to prevent " x-ing " from being used (note the spaces, which limit the string to a single word rather than any string which contains it).
--["Tree"][[DateTime(2009-01-31T10:30:00NZ)]] .