[Ardour-Dev] ardour3 video timeline
robin at gareus.org
Wed Jun 30 12:46:34 PDT 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 06/29/2010 03:33 AM, Patrick Shirkey wrote:
> On 06/29/2010 10:32 AM, Paul Davis wrote:
>> 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.
..and the current video-timeline is also part of the canvas. It's
similar to the markers-bars not the rulers.
>>> 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
>>> item from the timeline to display in the edit canvas. They both have
>>> 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?
I refrained from changing ardour's source so far the Videotimeline only
adds code (apart from the wscript and ardour.menus.in).
Implementing a VideoTimeAxis::TimeAxisView requires to re-implement a
couple of functions. It'd need a RegionView, get_automation_..(), and a
route_group ; just to mention a few.
Then we'll need a VideoStreamView::StreamView for TimeAxisView's view().
and there we get into trouble: StreamView requires a RouteTimeAxisView
...but the VideoTimeAxis is not a Route.
Anyway I don't see the point of coding all this.
What would be the benefit of displaying it in the Track-part of the canvas?
Are we really dreaming of making ardour a fully fledged video-editor in
the not too distant future?
>>> 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
>> 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.
> I hope you don't mind revisiting this concept at the moment.
>>> 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
>>> 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
>> there's no magic to the canvas.
Well, the magic is how it's all tied together. Even with doxygen
class-inheritance diagrams it took me quite a while to get the picture
and I still don't see the full picture.
>> 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
> Thanks for that detailed explanation.
many thanks from me as well.
>> writing new canvas items is not very hard. integrating them into
>> ardour is harder but manageable.
Any help with that will be greatly appreciated.
>> 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
I love to solve hard problems :) Alas GUI programming mostly requires
patience which I often lack, so that's hard for me :)
An additional factor is that I'm only just learning the ardour codebase,
while I've been working with video libs for a while.
wc -l gtk2_ardour/*.[ch]*
wc -l `find libs/pbd/ -iname "*.[ch]*"` `find libs/ardour/ -iname "*.[ch]*"`
quite a lot to digest. and that's not even all of it, though the
relevant part boils down to a few thousand lines.
> It seems that he has solved these 2 items in relation to the ruler
> display area.
The ruler does not have anything to do with that.
a small part of (2) is done in the algorithm that computes which frames
to display depending on the current canvas zoom/scroll position. Those
video-frames are cached by ardour as Gdk::Pixmaps.
(1) is all part of an external video-decoding server which also includes
a larger (2nd level) frame-cache.
> What I am missing is the specifics on what is different between the
> ruler section and the edit section and why the rulers can't be dropped
> randomly anywhere on the edit canvas.
> Am I correct that the ruler is drawn on top of the edit canvas? or is it
> a seperate ruler canvas?
> Is it simply that the ruler widgets are not able to be drawn in the edit
> canvas because they are widgets and not canvas items?
yes, Paul answered this one.
> Sorry, if this is just rehashing an old discussion. What I am trying to
> do is understand the issues that Robin faces so I can assist with
> implementation details.
your help is most welcome. Let me finish some initial work that ties
things together and get the current prototype to work.
..and then revisit the ardour integration. It is indeed the "easy" part
of the project but nevertheless probably the most time-consuming.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Ardour-Dev