Christian Thaeter | 15 Sep 16:38

Low level interface foundation for review

I've prepared the basic foundation for declaring and defining interfaces 
(for real now). So far I tried to reduce it to the bare minimum needed 
for the functionality.
Notably interfaces are versioned, but their functions and instances are 
not versioned here. This should be subject to be versioned somewhere 
else (when required).
Descriptors for querying metadata from an interface implementation are 
realized as interfaces themself (i'll show up examples next).

This system needs some careful review now because we will stick to it 
once it is finalized. Please take a look and let us discuss any changes 
you want. I tried to make it very low level and keeping only the 
essentials in the core, it was some pita to make it compatible with C 
and C++ (with some gnuism's, don't try to compile it with -pedantic). 
Documentation is partially finished but it might be that I failed to 
explain some intentions behind its design, when you question these this 
would be great help to improve it.

The code is in src/lib/interface.h in my 'devel' branch:
http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/lib/interface.h;hb=devel

Note: please do not merge my 'devel' branch into your sourcecode, its 
going to be rebased.

Whats next:
  * add a macro to call functions through interfaces
  * preparing some examples how it is used (as part of the testsuite)
  * a simple implementation for interface descriptors
  * provide a tool to generate uuid's for the implementations
  * plugin loader, plugindb, ...
(Continue reading)

Christian Thaeter | 15 Sep 20:46

Re: Low level interface foundation for review

...
> Whats next:
>   * add a macro to call functions through interfaces
>   * preparing some examples how it is used (as part of the testsuite)

WIP at:

http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/library/test-interfaces.c;hb=devel
Christian Thaeter | 16 Sep 11:11

Re: [Lumiera-work] INFRASTRUCTURE build and test system on the server

Michael [Plouj] Ploujnikov wrote:
> Christian and I already started playing around with the builddrone
> implementations
> (http://git.lumiera.org/gitweb?p=builddrone/ct;a=summary and
> http://git.lumiera.org/gitweb?p=builddrone/plouj;a=summary).
> 
> I was trying to think how to implement a usable script for this
> system, but I ran into a few questions that I can't answer myself:
> 1. How do we organize or track relationships between functions in the
> soup directories which refer one to another. For example, both GitPull
> and Doxygen might use the AddToReport function. Should the AddToReport
> definition be duplicated in the files for both of the other files? How
> will Bash handle sourcing the same function twice? What happens if the
> two versions of AddToReport start to differ? Should we put AddToReport
> in a separate file which is sourced by the files where GitPull and
> Doxygen functions are defined?

Generally this soup shall only define functions and rather not execute 
anything else (it would be possible but can't rely on other functions 
then). Further, this all is very sketchy and has some rough edges which 
need to thought about. Thats more a design and definition issue.

For example: each scriptlet shall log its output in its own log 
(,git.log, ,doxygen.log, ...) actually we might even define that all 
this logs have some well defined format. My suggestion would be asciidoc 
which in the simplest case just places all in a listing block:
echo -e ".Git Pull Log\n-----" >,git.log
echo -e ".Git Pull Errors\n-----" >,git.err
git pull 1>>,git.log 2>>,git.err
echo "-----" >,git.log
(Continue reading)

Picon

Idea

This is what i am looking for! The middle window is a preview from the resource list (video images sound an so on), and the right one shows the result from the timeline. I guess there is nothing new, but i don't beleve it has to be! it's just what i want!
_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
Christian Thaeter | 16 Sep 20:54

Announce: local search engine

Simeon set ht://dig up, we can now search cinelerra.org lumiera.org and 
some related sites on our server.

http://lumiera.org/search.html

I am not very impressed with the performance so far, this may need some 
tweaks. So far this is only a try, it could happen that we change the 
search engine sometime in the future. If someone has experience with 
this, please make suggestions.

	Christian
Ichthyostega | 17 Sep 02:40
Picon

Re: Idea


John Sunnert Kjerstadius schrieb:
> This is what i am looking for! The middle window is a preview from 
> the resource list (video images sound an so on), and the right one 
> shows the result from the timeline. I guess there is nothing new, but
> i don't beleve it has to be! it's just what i want!

Hi John,

yes, agreed, such an arrangement of the viewers is within the scope what
we are planning. But the idea was to have more flexibility with the
viewer(s). Like being able to attach a viewer at "probe points"
somewhere in the middle of a processing pipe.
Besides, the other idea we were discussing the last days was to handle
the "media preview" more like another timeline, i.e. when needed a
timeline would be created on-the fly for any clip you are viewing.
You could then use this temporary timeline to precut preview and
add some elementary colour correction etc. Any such timeline could
be added to the main timeline as a meta clip, or just used as a source
for copy-n-paster, or simply discarded altogether when not needed any
longer.

	Hermann

PS: nothing of this is final yet, but it's well within the scope
what is possible with the technology we are developing...

IL'dar AKHmetgaleev | 17 Sep 02:51
Picon

Re: Idea

На Tue, 16 Sep 2008 18:00:10 +0200
"John Sunnert Kjerstadius" <john.sunnert.kjerstadius <at> gmail.com>
записано:

> This is what i am looking for! The middle window is a preview from the
> resource list (video images sound an so on), and the right one shows
> the result from the timeline. I guess there is nothing new, but i
> don't beleve it has to be! it's just what i want!

http://www.videohelp.com/toolsimages/kdenlive_542.jpg
Is it what are you searching for?

--

-- 
Срд Сен 17 08:51:04 KRAST 2008
Wed Sep 17 00:51:04 UTC 2008
----------------------------------
Visit my home page http://akhilman.blogspot.com/
----------------------------------
jabber: akhil <at> jabber.ru
----------------------------------
Пытаться сделать мир на 1/6.7e9 лучше
Ахметгалеев Ильдар aka AkhIL
----------------------------------
Linux artstation 2.6.25-gentoo-r7 #1 SMP Mon Aug 11 08:02:41 KRAST 2008
i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux up 2 days, 19:26,
1 user,  load average: 0.26, 0.07, 0.02
_______________________________________________
Lumiera mailing list
Lumiera <at> lists.lumiera.org
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
Daniel Jircik | 17 Sep 06:59
Picon

Re: Marble and Clay [quote Walter Murch]

Thanks for that refreshing read. As an old film editor with a lot of Moviola/Kem experience I think these are some great architectural points.
----------------
"The Moviola system "emulsifies" the film into little bits (individual shots)
and then the editor reassembles it out of those bits, like making
something out of clay. You take a little bit of clay and you stick it
here and you take another little bit of clay and you stick it there.
At the beginning of the process there is nothing in front of you,
then there is something in front of you, and then there is finally
the finished thing all built up out of little clay bricks, little
pellets of information."
--------------
When you cut on Moviolas you cut all the pieces out of your stock with sound from bins. Sticking one after the other in order until you have a movie . This works great and fast and is actually quite fun. The problem arises with the inability work multi-track or  multi-camera.

Cinelerra is very much the Moviola system in that you have "The Viewer" and "The Compositor" This is  analogous to creating your clips in the Viewer and syncing up film sound on a sync block with a splicer , taping them together and dumping them into bins.

---------------
"With the KEM system, I don't ever break the film down into individual
shots -- I leave it in then-minute rolls in the order in which it came
from the lab. In sculptural terms, this is like a block of marble -- the
sculpture is already there, hidden within the stone, and you reveal it
by taking away, rather than building it up piece by piece from nothing,
as you do with clay."
--------------

 I used a first generation moviola flatbed , moving on to a 2 head Steenbeck. With 2 audio tracks you were working with four "chunks of marble" The beauty of this system is the ability to lock, unlock, and jog transport with impunity. Cut snip and move on down the line.   Now it's no longer the editing room it's the editing suite.

--------------
"Computerized digital editing and, strangely enough, good old-fashioned
Moviola editing with an editing assistant, are both random access,
non-linear systems: You ask for something specific and that thing --
that thing alone -- is delivered to you as quickly as possible. You are
only shown what you ask for. The Avid is faster at it than the Moviola,
but the process is the same."
---------------

Strictly from a user perspective to turn the room into a suitte here is how i would envision it.

Creating a new project would be essentially the same , separate windows for viewer, compositor timeline
With the Steenbeck you can click a button and shuttle something forward reverse click the button again and playback in sync.

When you add a video track, you should be able to open it up in a separate viewer. Use the viewer to jog back and forth lining up your shot then locking it to the master timeline control. Then instead of making clips and overwriting into the timeline just specify in, out points, being able to attach transitions to that point. wipe dissolve etc. That way comparative decisions are easier to make as well as change. The same should apply to audio as well. Playback transport that you can lock and unlock to the master timeline. Dragging a mouse over something and moving it one way or the other and seeing how it works is not the same  as running side by side. T his is where a midi jog wheel interface would shine.

Taking that concept one step further, The viewer itself should be a sub itertation of the whole program. Thus being able to make whole decision lists into "clips". This would vastly simplify dealing with large complex projects that need to be broken up into manageble chunks, ie: scenes.

My 2 cents.

Kind Regards,
Daniel Jircik
http://reggaecobras.com

_______________________________________________
Lumiera mailing list
Lumiera@...
http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
Gour | 17 Sep 08:33
Picon
Gravatar

[CinCV] Re: Announce: local search engine

>>>>> "Christian" == Christian Thaeter <ct@...> writes:

Christian> Simeon set ht://dig up, we can now search cinelerra.org
Christian> lumiera.org and some related sites on our server.

htdig is still alive?

Christian> I am not very impressed with the performance so far, this may
Christian> need some tweaks. So far this is only a try, it could happen
Christian> that we change the search engine sometime in the future. If
Christian> someone has experience with this, please make suggestions.

Why not only localized Google search?

Sincerely,
Gour

--

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------
Christian Thaeter | 17 Sep 11:00

Re: [CinCV] Re: Announce: local search engine

Gour wrote:
>>>>>> "Christian" == Christian Thaeter
<ct-dtRWZPArUE0dnm+yROfE0A@...> writes:
> 
> Christian> Simeon set ht://dig up, we can now search cinelerra.org
> Christian> lumiera.org and some related sites on our server.
> 
> htdig is still alive?
> 
> Christian> I am not very impressed with the performance so far, this may
> Christian> need some tweaks. So far this is only a try, it could happen

Fixed now, it is fast

> Christian> that we change the search engine sometime in the future. If
> Christian> someone has experience with this, please make suggestions.
> 
> Why not only localized Google search?

because we can and generally I like to support anti-monopolism.

> 
> 
> Sincerely,
> Gour
> 
> 

Gmane