[Ardour-Dev] ardour3 video timeline

[Paul Davis]

On Mon, Jun 28, 2010 at 8:18 PM, Patrick Shirkey
<pshirkey at boosthardware.com> wrote:

> Thanks again for the explanation. Is the timeline a canvas too?

i suspect that by "the timeline" you mean the set of rulers above
tracks. its actually a mixture. the editable components are all on a
canvas; the rulers are actually widgets.

> I'm not sure I fully grok the issue but going with the information I have so
> far it seems that it should be a case of joining the dots to get a canvas
> item from the timeline to display in the edit canvas. They both have access
> to the actual timeline else it wouldn't be possible to sync them. So I
> wonder why Robin has found it requires so much code as to make it
> particularly difficult? Is the problem that the edit canvas has all the
> hooks & returns for editing that are not available for the timeline so the
> code falls over as it is not receiving enough information from the a
> timeline item?

there is no "timeline item". there is a canvas used by the editor.
various horizontal items are placed on it, which correspond to tracks.
within those items are subitems, which correspond to (e.g. regions)
and within those are sub-sub-items and so on ad infinitum.

> I'm not suggesting it should be a priority for you or anyone else but it
> seems there is an opportunity here to make the edit canvas a bit more
> flexible.

there is no such oppurtunity. the current canvas is quite flexible
enough, and the areas in which it is deficient require us to switch to
an entirely new canvas implementation, something that has been on the
TODO list for many years.

>In other words it should be possible to have tracks that can't be
> edited displayed in the edit canvas. This would potentially open up the door
> for other non editable canvas items such as a "master waveform".

there are already such tracks. and there are already non-editable canvas items.

> It would for example provide a way to embed plugins into the edit canvas,
> Spectrum analysis items, pretty much any canvas item that it not fully
> editable could be tested that way.

i'm not sure you understand the architecture. you need to think in
different terms than you are right now, i think.

a canvas is basically a drawable, scrollable area. canvas items have a
position and size on the canvas, and are composited ("layered, with
opacity") by the canvas. each item draws itself onto the canvas when
told to do so. what it draws is up to it, and only it. each item can
receive events (keyboard, mouse and all the other events accessible to
widgets), which it might handle by itself, or simply pass it along to
its parent, which might handle it or pass it along to its parent and
so on until it reaches the top level canvas, at which point it enters
the "normal widget heirarchy" just as it would without any canvas
items.

there's no magic to the canvas. its just a set of code that draws
stuff and handles events. the major difference is that it supports
z-axis "stacking" and supports drawing with opacity or "alpha channel"
which historically widgets did not do. when you drag a region or a
control point around all that is happening is that the canvas is
telling the items in the area where it used to be to redraw, and the
items (including the region/control point) where it now is to redraw
also. the result is a new "image" of the canvas, and that is what you
see.

writing new canvas items is not very hard. integrating them into
ardour is harder but manageable. robin faces some MUCH harder problems
than this (which he has solved before, mostly) that relate to (1)
obtaining the data to display (2) caching it appropriately so that
scrolling and other activities are handled efficiently. this stuff is
hard.

--p