[Ardour-Dev] ardour3 video timeline

[Patrick Shirkey]

On 06/28/2010 11:38 PM, Paul Davis wrote:
> On Mon, Jun 28, 2010 at 9:19 AM, Patrick Shirkey
> <pshirkey at boosthardware.com>  wrote:
>    
>> Thanks for the quick explanation. Is that primarily to enable functionality
>> like multi track drag/select/cut/paste etc... ?
>>
>> How is each track/bus drawn and positional info retained? Is there the
>> equivalent of parent->child relationship between the canvas and the
>> individual track/bus?
>>
>> Couldn't the code that handles displaying an audio/midi track/bus be
>> extended to allow any "child" track/bus type?
>>
>> I guess I'm wondering about the logic behind making the editor canvas
>> inflexible in this regard.
>>      
> the key point is that the objects on the canvas are not widgets that
> can be used without the canvas. they are canvas items, whose internal
> implementation is closely tied into the internal design of the canvas
> itself. its still quite object-oriented in all the right ways, but not
> using widgets that could be re-used in a totally different context. to
> give a specific example: some of the ideas about how ardour draws
> waveforms come from something that was called GtkWaveView. that was a
> regular GtkWidget which could be used just like a toggle button,
> textview or whatever. but the current (and foreseeable future) design
> of GTK means that you can't use widgets the way that you need to
> create the experience you expect from a non-linear, non-destructive
> multitrack editor. so some of that code ended up in the
> CanvasWaveViewItem object, which draws itself onto a canvas. its
> modular, its compact, but its also useless without the canvas.
>
> there is still a heirarchy of objects/items on the canvas, specific
> track types etc. etc. - they just don't involve "widgets" in the
> normal sense of a GtkWidget.
>
>    

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

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?

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. 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".

Would it be a case of going through all the code and adding cases for no 
information to be returned? I can see why this would be a hassle to 
insert but it seems to me like it would make the canvas quite powerful 
as we could then have all sorts of canvas items that we haven't thought 
of yet.

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.


-- 
Patrick Shirkey
Boost Hardware Ltd