Ableton Forum

Hello there.

I am getting to grips with live 5, and i have always wondered from testing the demo why the GUI is sluggish.

A user switching from cubase, this is quite fustrating. It seems quite sluggish and choppy. For example, when playing back and having the Follow feature on, or just casually moving the page around in the arrange view.

It reminds me slightly of the comparison of internet explorer and firefox.

Even though firefox is better [wink] it seems slow compared to rendering pages (scrolling up and down) than internet explorer.

Is it because Live 5 is not codec via C++?.. and coded via java or something similar instead?

thanks,

josh.

Depends , some people on the forum have reported serious GUI latency with the last updates , though it seems not everyone is affected.

I only get problems if I run my laptop on batterypower , otherwise it works fine.

You might consider going for version 4 if it's functionalities are enough for you , that one runs fine for everyone I think.

Are you kidding me?..

I'm not going to version 4 just because the live 5 team can't sort out the problems they have with it... this isn't another cubase failure is it??

It's not huge latencies i'm getting, it's just lagging.. choppy, sluggish.

Like, the difference you would notice when playing a game at 60fps over say, 10/15fps.

Live is definitely coded in C++. I have also noticed that the GUI is slower than in version 4, but I can't give you a definite answer as to why because, well, I'm not an ableton developer, obviously. Much speculation has been made as to how the GUI was written, and based off of some basic exploration, I think that the general consensus is that Live was developed with it's own GUI toolkit, since it doesn't seem to link to any of the major system ones.

sad gui is slow when runs vst and audo. the more things the worst it getting. Your are cubase user so thinking you will have hard time with live to use as mainsoftwares daw. To use as rewire for audio looping is ok but the vst and more live synth trackings becomes frustrates quickly. I like cubase and I like the cpu miles from it. Live could be best daw on planet if the bugs and gui problem were vanishings. Peoples here split the camp. Some say no problems others have big problems. I reasoning those with no problems use little vst synth and fx if they will they freeze quick to make audio only. Live play audio only works good it is when live midi vst added you getting pops clickings and many others. bad things So sad live was the best in 4. I wait for 6 if it is no good I leave live for good.

how could anything possibly be slower than IE

I'm not going to version 4 just because the live 5 team can't sort out the problems they have with it... this isn't another cubase failure is it??

I'm only suggesting an option for if you really want ableton fucntionalities like the scene-view and don't trust the 5.X and don't need the extra FX.
You wanted to know if there were GUI problems , yes , for some there are in 5.X. So if you can't live with that but need a full DAW , you might be better of with another DAW. If you just want the scene-view thingie , get 4.X , it's the cheapest solution anyway and you can always upgrade later.
It's a free world you know , there are other DAWs out there.

Maybe Ableton could re-write the UI in OPEN GL 2.0 so as all the burdon would be taken by peoples graphics cards rather than processor.

I'd suspect that the GUI is running in its own thread, so the audio engine takes priority. This doesn't excuse the behaviour, but at the very least the audio doesn't get interrupted. I'm sure it's all C++, and the UI is just a pixel map. But perhaps it is so customized, as to just have one code-base for OS X and Windows, that the Win32 (Windows) framework isn't utilized and the CoreGraphics (OS X) framework isn't utilized. Who knows...

joshier wrote:Hello there.

I am getting to grips with live 5, and i have always wondered from testing the demo why the GUI is sluggish.

A user switching from cubase, this is quite fustrating. It seems quite sluggish and choppy. For example, when playing back and having the Follow feature on, or just casually moving the page around in the arrange view.

It reminds me slightly of the comparison of internet explorer and firefox.

Even though firefox is better [wink] it seems slow compared to rendering pages (scrolling up and down) than internet explorer.

Is it because Live 5 is not codec via C++?.. and coded via java or something similar instead?

thanks,

josh.

joshier wrote:Are you kidding me?..

I'm not going to version 4 just because the live 5 team can't sort out the problems they have with it... this isn't another cubase failure is it??

I'm still on Live 4 and very happy with it. I can't really see any compelling reason to upgrade.

BTW, Live 6 was just announced. Q3. No features disclosed, except support for multi core processors.

I conducted some tests and it seems that the main .exe (when set on high priority) takes president over the audio thread.

I found out this when trying to avoid audio clippings, i decided to whack the Live 5.0.3.exe thread to 'high' in task manage and noticed that when moving the GUI (sliders etc ) the audio slowed down.

I honestly think they need to take a seriouse look at it, i hope a guy knowledgable on the GUI system pops in here to tell me the difference between the way SX3 is coded and the way Live 5 interface is coded, i've always been interested in that kinda stuff.

I'd also like to know how hard it would be to change..

my gui is choppy as hell, and has been since live 3, but only when a very complex arrangement is playing, with loads of effects, vstis, etc

scrolling around, resizing the wave editor view, etc etc -- all very slow in response until i hit stop. Otherwise, it's fine. And yeah, it bugs the hell out of me but it's also something i'm used to as well

I second the GPU GUI idea -- with Windows Vista coming i think MS will have an API native to the OS for doing such things..

bizack wrote:I'm sure it's all C++, and the UI is just a pixel map. But perhaps it is so customized, as to just have one code-base for OS X and Windows, that the Win32 (Windows) framework isn't utilized and the CoreGraphics (OS X) framework isn't utilized. Who knows...

I think this is the case, too... makes Live more portable but probably kills performance a little.

GTK+ is pretty cross platform