Re: [LMMS-devel] What is the eta for the fully functional LMMS qt4 release?

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

Am Dienstag, 18. September 2007 20:56:59 schrieb Paul Giblock:
> I remember, a while ago, people were complaining about how long it
> took to load a song. (Or even unload a song).  I think this was around
> the time we went to the zipped project files.  Anyways, the big
> problem was creating TONS of Widgets (controls).
That's indeed the BIG problem... there are minimal about 200 widgets per=20
instrument-track - almost no problem with Qt3 (although loading a song stil=
l=20
could take up to 10 seconds).

> My original thought was to create a pool, or some sort of cache for
> these instrument windows/dialogs.
When do you want to create it? Still takes lot of CPU (and especially waste=
s=20
unneccessary memory).

> Or, at least a deep-copy=20
> constructor that may perform faster than constructing from scratch.
Hm the problem is that the QWidget-constructor is the actual slow part and=
=20
QWidget (and all its subclasses) do not provide a copy-ctor.

> Fast forward to now.  QT4 is nice, but slow.  We have a bunch of
> channels/insruments with a bunch of controls and each control is SLOW.
> Quasi-Big-O-Notation says:  O(n*n*slow) =3D "Sucks alot".
>
> Now, let me ask you this:  How many instrument windows do you have
> open at a time?
Probably not more than 3-4.

> How many instrument windows do you actually need open=20
> at a time?
The same I guess :P

> Finally, doesn't have 20+ instruments open at a time get=20
> very cluttered very fast?
That's not the point - the point is to once create all of them no matter=20
whether they'll be opened or not.

> We have one song editor.  We have one beatline editor.  We should have
> one instrument window at a time.  This way instead of O(n*n*slow) we
> have O(slow) which =3D "tolerable".  This is what FLStudio does, and
> I've never heard anyone complain about that.  Construction/Destruction
> will be alot faster.
I wouldn't like that way! What if you want to copy the value of some knobs =
per=20
Drag'n'drop (press <Ctrl> and "drag" the knob onto another).

> Sure, some plugins will need to be redesigned slightly, or we may just
> need to manage it better at at widget-level.  Every instrument creates
> it's GUI on startup, and it uses Knob-values and stuff in the
> calculations.  So, either the instruments must defer UI creation, and
> use variables in addition to knobs.  Or, we need to allow controls
> such as Knobs to exist in a sort of abstract state where all they have
> is a value, but they do not redraw, they have no parent, etc.. Then we
> fix the UI when the user tries to few the PLUGIN tab.
My thought was to make use of the outstanding separation of GUI /=20
data/functionality. When loading a song, none of the GUI (but the already=20
existing song-editor etc.) is being created and only the data of the plugin=
s.=20
Now the GUI is created on-demand, i.e. if you click the=20
instrument-track-button. What about this? Another question then would be=20
whether to destroy the window or not. It'd be also possible to just create =
a=20
few (let's say 3-4) instrument-track-GUI's and use them as views for the=20
data/models - only problem is the actual plugin-GUI - it could be "cached"=
=20
and the top-level-widget of the plugin-GUI reparented accordingly... howeve=
r,=20
let's discuss about that after we finished with the basics...

toby

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