From: Stephane T. <st...@ne...> - 2006-09-24 11:53:24
|
Hi, This lmms version works fine for me, no more "display problem", LADSPA effects are availables. Some "bemols" : - All effects in old songs are gone... Nevermind, this is an occasion to make some better ones :) - There is always a segfault if (while playing) you attempt to add a ladspa plugin if "effects chain" is "on". You must set this diode "off" before you add a plugin, otherway it segfaults. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1507087440 (LWP 29003)] 0xa7d08e29 in QMutex::tryLock () from /usr/lib/libqt-mt.so.3 (gdb) bt #0 0xa7d08e29 in QMutex::tryLock () from /usr/lib/libqt-mt.so.3 #1 0xa728d1cb in ladspaControl::getValue () from /usr/local/lib/lmms/libladspabase.so.0 #2 0xa680d43b in ladspaEffect::processAudioBuffer () from /usr/local/lib/lmms/libladspaeffect.so #3 0xa7147880 in __malloc_initialize_hook () from /lib/tls/libc.so.6 - I noticed that it takes a long time to unload a song which has many instruments. I admit loading instruments takes a long time (I had seen that Cubase on Windows is slow too) but why does "unloading" is so long in lmms ? Ok, that all I can tell after a quick test, I'll hardly try to get some freetime this afternoon to have a deeper opinion on this new release. Stef |
From: Tobias D. <tob...@gm...> - 2006-09-24 18:20:08
|
Am Sonntag, 24. September 2006 13:53 schrieb Stephane Thomas: > Hi, > > This lmms version works fine for me, no more "display problem", LADSPA > effects are availables. good to hear this ;-) > - All effects in old songs are gone... Nevermind, this is an occasion to > make some better ones :) yeah, "of course" the format for saving effects has changed after I made up= =20 the generic effect-framework. You can't do anything ;-) It also changed=20 yesterday, but for this you can either edit your mmp-file and replace the=20 string "controls" with "ladspacontrols" or setup all parameters of the=20 effects again ;-) hopefully this is the last time, the format is changing, = so=20 we can make a new release within a few weeks... (I want LMMS 0.2.2 with=20 effect-, free VST- and STK-support to be in debian etch which is going to b= e=20 released in Q4 AFAIK) > - There is always a segfault if (while playing) you attempt to add a > ladspa plugin if "effects chain" is "on". You must set this diode "off" > before you add a plugin, otherway it segfaults. hm, the whole effect-system isn't very stable yet, especially VST-effects b= ut=20 I hope this will change in the next days... > - I noticed that it takes a long time to unload a song which has many > instruments. I admit loading instruments takes a long time (I had seen th= at > Cubase on Windows is slow too) but why does "unloading" is so long in lmms > ? the problem is as usual in Qt (of course not in the own software! ;-) ), wh= ere=20 deleting all the QObjects and QWidgets (which are several thousands in a=20 usual song) is quite slow and has a lot of overhead - the disadvantage of a= ll=20 the convenience Qt gives to developers... this problem is even worse with=20 Qt4 :-( it seems that we can't do anything but stopping to develop LMMS for= =20 not blowing it up with new features ;-) > Ok, that all I can tell after a quick test, I'll hardly try to get some > freetime this afternoon to have a deeper opinion on this new release. new release? you mean current revision ;-) toby |
From: Joel M. <joe...@gm...> - 2006-09-26 08:18:42
|
Eyh! Why don't contact the Qt developers about this= > the problem is as usual in Qt (of course not in the own software! ;-) ), where > deleting all the QObjects and QWidgets (which are several thousands in a > usual song) is quite slow and has a lot of overhead - the disadvantage of all > the convenience Qt gives to developers... this problem is even worse with > Qt4 :-( it seems that we can't do anything but stopping to develop LMMS for > not blowing it up with new features ;-) > |
From: Tobias D. <tob...@gm...> - 2006-09-26 09:15:58
|
Am Dienstag, 26. September 2006 10:18 schrieb Joel Mandell: > Eyh! Why don't contact the Qt developers about this= they can't do anything, that's the disadvantage of a complex C++-framework... toby |
From: Paul G. <dr...@gm...> - 2006-09-27 04:29:18
|
Maybe creating a widget pool/cache is in order? On 9/26/06, Tobias Doerffel <tob...@gm...> wrote: > Am Dienstag, 26. September 2006 10:18 schrieb Joel Mandell: > > Eyh! Why don't contact the Qt developers about this= > they can't do anything, that's the disadvantage of a complex > C++-framework... > > toby > > |
From: Tobias D. <tob...@gm...> - 2006-09-27 06:55:09
|
Am Mittwoch, 27. September 2006 06:29 schrieb Paul Giblock: > Maybe creating a widget pool/cache is in order? this would work for shared data such as pixmaps etc., but as we need to cre= ate=20 separate widgets (of many different types!) for each displayed element, I=20 can't imagine how this should work... things would get even more complex, i= f=20 we would save pointers to widgets and their type somewhere instead of=20 deleting them when closing the song, just for hoping that we can re-use the= m=20 somewhere in the new song... but maybe it helps a bit to introduce=20 pixmap-caches for drawing-operations as well as for artwork used by several= =20 widgets, so pixmap-files to not have to be loaded each time e.g. a knob is= =20 created (which is usually done several hundred thousands of times) and so=20 on... I'll try to figure out how this could work... toby |