The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This `supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it.
Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout.
- The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.
- The core dev responsible for the GUI is _joelholdsworth_ (Joel Holdsworth).
- One of the group goals is to create a dialogue between the developer's point of view and the editor's point of view.
The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs.
It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. +
There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack.
For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality.
The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend.
It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning.
It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server.
It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks.
For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later.
NOTE: Demonstration in https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/common/guifacade.cpp;h=60a16d0f67bd95b43e44662daa9c0525235e14f5;hb=5f10e65852de2c51364c2e2a5a1cf29cae81c6b2#l64[guifacade.cpp]
(The thread shall be forked from within the GUI code not from the facade)
This was discussed and ichthyo has already pushed a new cleaned up state and resolved most of the dependency problems with the liblumiera. It raised the question: do we prefer a UI facade to a GUI facade or do we want an extra script facade someday?
It was discussed whether _joelholdsworth_ should wait for _cehteh_ to make a playback interface or use a dummy one for now.
_Cehteh_ wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Ichythyo has been using the `GuiNotification` as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which _cehteh_ and _joelholdsworth_ planned to flesh out in the near future.
A new Nobug is nearly ready with new documentation (cehteh). The error handler has been improved, as announced on the ML. Cehteh emphasised the importance of using nobug everywhere and not `#if DEBUG`:
DEBUG is not a standard C/C++/buildsystem defined macro when it works its just coincidence but NDEBUG is standard. Neither does such code use nobug facilities nor respect nobug build levels.
in new nobug you can do:
NOBUG_IF_ALPHA(
alpha code here
)
it's the same for BETA RELEASE and there's a NOT variant for each but even then that should be avoided and higher level nobug facilities should be used instead.
Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say ``don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup''. This is where the tree of tracks plays an important role because each track with its children forms a group.
There was further discussion on the general aims, objectives and focus of Lumiera and the reasoning behind them. Integration with control surfaces, jog wheels, sliders etc. should also be considered for the workflow. Nikola expressed the importance of stability and a simple and clean UI.
Next meeting
------------
Usually meetings are the second Wednesday each month on #lumiera at Freenode. The next meeting will be on Feb 11 - 20:00 UTC
Core dev's IRC meetings
~~~~~~~~~~~~~~~~~~~~~~~
cehteh proposes a recurrent core dev meeting, more frequent than the monthly meeting since there is the a lot of stuff ahead that needs communication.
