[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] Helping with development -> where do I start?

From: Remon Sijrier
Subject: Re: [Traverso-devel] Helping with development -> where do I start?
Date: Sat, 19 Jul 2008 20:26:11 +0200
User-agent: KMail/1.9.9

Hello Peter,

Good to see yet another person with a radio organization background who found 
Traverso, somehow Traverso seems to be very suitable for radio broadcasting 

Your idea of hard selecting a part of a clip is something I started working on 
some time ago, but unfortunately didn't finish it yet, due lack of time.

About where to start, hmm. Lets see.

Traverso is build up with a number of say modules, implemented as libraries. 
The core library that has a number of classes that implements the 'real'  
objects, like Sheet, Track, AudioClip etc.
The sheetcanvas lib that has classes that give a visual representation of the 
visual core objects, those classes are named like their counterpart appending 
View to them.

Then there is the 'glue' between the core and the gui classes that is the 
contextual interface. Each key/mouse event is catched by the ViewPort class 
who sends those events to the InputEngine who parses them. The event 
eventually is dispatched to the appropriate object below the mouse pointer, 
using Qt's signal-slot mechanism.

The returned Command object then is finally used to initiate the action and 
storing the history. The re-implemented do_action() and undo_action() are 
responsible for this.

Actions are performed by the core objects who are responsible for thread 
safety, which in turn is managed by the Tsar class (you'll find that one in 
the 'common' dir)
E.g. Track has a set_gain() function, which sets the gain and afterwards emits 
a signal to indicate that the gain has changed. The TrackView receives this 
signal, and updates itself to reflect the change.

Command objects can also be returned from the CommandPlugin system, if you 
browse that code it'll become quickly clear how that works, if not, please 
The idea behind the CommandsPlugin is to remove code like this:

Command* Track::add_plugin( Plugin * plugin )
        return m_pluginChain->add_plugin(plugin);

to keep the core code as clean as possible, and give developers the chance to 
add new feature without messing with the core objects.

class member variables have a prepended m_beforeTheNameOftheVariable, 
function_names_are_like_so() and signalsLikeSo

Well, need to go now, if you need explanation, just ask here, and I'll see 
what I can do!

> Thank you very much for your consideration and thank you so much for
> this application!

You're welcome!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]