[LMMS-devel] Roadmap + changes in SVN-infrastructure

[Tobias D. <tob...@gm...>]

Hi,

starting with the 0.3.0 release the development is now splitted. First ther=
e's=20
the stable 0.3.x-series which will only experience bug-fixes etc. while I=20
forked 0.4.x for development-purposes only. That brings some changes in=20
SVN-infrastructure:

svn co https://lmms.svn.sf.net/svnroot/lmms/branches/lmms/stable-0.3

gives always a snapshot of the 0.3.x-series (which will be interesting for =
the=20
most of you) while with

svn co https://lmms.svn.sf.net/svnroot/lmms/trunk/lmms

you'll get a developer-snapshot (0.4.x-series).

Now what am I planning to do? The biggest change will be the complete=20
Qt4-support of 0.4.x. This also means that Qt3-support will be dropped. Thi=
s=20
allows us to concentrate on the real important things and not spent the tim=
e=20
in writing this horrible "hybrid" code. The usage of Qt4 will bring/allow=20
further improvements:

=2D more beautiful and powerful GUI:
  * anti-aliased lines e.g. in envelope/LFO-tab of instrument-track or the
    master-output-graph at the top etc.
  * more gradients in GUI-elements as we can use QLinearGradient etc. for
    simply realizing gradients - so far we needed separate nasty code for t=
his
  * more fading-effects at several places and simplification of existing on=
es
  * maybe OpenGL-accellerated visualization-plugins
  * better rubberband and all that in piano-roll, song-editor etc.
  * improved MDI-support which allows developing a panes-interface=20
    (see http://doc.trolltech.com/4.3/qt4-3-intro.html#main-window-styles)
  * and much more...

=2D better threading-support
  * per-thread-event-loops will allow us to writer more elegant and maybe
    also faster code
  * using QtConcurrent from Trolltech-Labs or similiar technologies we can=
=20
    write code for parallel rendering very easily! Thus we get full and real
    SMP-support

=2D native win32-port (although this has low priority)

=2D more stuff I can't remember right now


Another big thing I want to realize is a strict separation of GUI and actua=
l=20
data/functionality. The goal is to be able to load/play/render files withou=
t=20
any GUI running (i.e. no running X). Why? For example for running benchmark=
s=20
without any side-effects because of the GUI. But what's more important in=20
this concern: I want to externalize all functionality of LMMS into a shared=
=20
library and thus make the actual lmms-binary a small application which is=20
linked against this library and starts it up. But even cooler things could=
=20
become true: other projects (such as Rosegarden, Hydrogen etc.) can use thi=
s=20
library and thus open/play/render LMMS-projects or presets and thus use=20
LMMS-plugins - either with GUI enabled if the according application is Qt4=
=20
(KDE4) based or without any GUI and just playing the sounds. Imagine mplaye=
r,=20
xine etc. supporting to play mmp(z)-files via an according plugin which use=
s=20
the LMMS-library! :) (just one possible scenario).

This is what I all have in mind - don't know yet, until when I'll be able t=
o=20
implement which things but I think we have at least a properly working=20
Qt4-version with *some* of the improvements listed above at the end of this=
=20
year.


toby


=2D-=20
=46reiheit statt Angst -- Stoppt den =C3=9Cberwachungswahn!
Demo in Berlin, Samstag 22.09.2007
www.freiheitstattangst.de