[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
work...
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
ask!
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!
Remon