Application "Stickiness" in Win XP ...

[supster]

My comp does the same when I'm moving alot of Big assed samples around for Dj ing. Basically I think it's to do with the fact that audio has main priority over screen refreshes and the like. Which means that there is never a hiccup in the audio stream "pretty essential for live work" . I know if i do the same things in Sonar then the screen refresh has priority over the audio and my sound goes all squmaibflebled up. I know which one I would rather

Yeah, its actually pretty amazing how the audio holds up in a situation like that. I've had the screen completely locked up, no refresh, and the audio is still playing without missing a beat ...

However this happens to me at avg resource usage - when cutting / copying . pasting small clips ...

Also - zooming. Which should have nothing to do with disk access or file size. Its only zooming on the grid.

[supster]

Update:

Installed a brand new Hitachi 160 Gb, 8 MB buffer 7200 RPM drive as a dedicated audio drive just now.

"Stickiness" is more or less gone Seems like I can zoom, copy, paste etc much faster than before.

Though Im still not sure what the HDD access had to do with zooming, guess I can live with not knowing for now ..........

[Sly One]

Exactly the same happens here - I'd not thought about it, so well done!

On a busy project (say 20 tracks, most with EQ, perhaps comp, some VSTis, some VST effects, stuff on the Master, a bit of routing here and there, Reason rewired) if I click and drag a group of clips, say 10-20 at a time, ESPECIALLY while the music is playing, there is a pause of 5-10 seconds before Live catches up. I am ready for this now so I just keep the mouse held down and drum my fingers till the transparent versions appear under my pointer, but at first I was giving up before it caught up, and dropping copies all over the place, severely messing up my project.

So, hurray for undo, but it's still really annoying and slows down workflow.

I already knew I was short of memory, so I really should sort that out. Swapping to disk can't be helping. The hard drive is fast (Barracuda 7200rpm) and on a dedicated IDE channel though, separate from the swap file. Not what I'd expect..

[supster]

Yeah ... well ... I've always taken into account the massive calculations Live and your CPU have to do when it is burdened with a lot of data.

1- More running tracks

2 -More clips, warping all that audio simultaneously

3 - More VST's, your CPU and soundcard are generating all that in realtime

4 - Add power hungry VST's (reverbs, synths with tons of voices etc) ..

.. and its hard to expect it to run totally smoothly.

My issue was solved with the new hardrive. But when I'm running a project @ 80 / 90 %, thats another story

[myztmuzic]

We both have Athlon's.... I wonder if its the chipset ...

I'm suspicious of your VIA chipset.

Well, I have VIA-chipset on a MSI-board (not a year old yet) and i have never had any probs - i even managed the mLAN2-firmwareupgrade (Firestation) cause of that chipset. I run UAD-1 dsp-cards as well - no probs! But i run a P4 Prescott 3.2-2Gb ram and my audiodrive is a 10000rpm s-ata, but my systemdrive is only 7200rpm s-ata.
But it's not an Athlon, tho..

The Reaktor-probs is wellknown - it freezes/locks Live when launching in my DAW too - and i'm told this will be fixed in near future. It's Reaktor 4 in my case.

When it comes to mixed midi/audio tracks, Lives CPU-meter tips over (70-90% - that means crackles&pops!) after around 5-10 midi & 5-10 audiotracks (in the same project) - so my workaround here is to resample (or bouncing) the miditakes on the fly, and delete the midi-stuff. If you prefer bouncing, it does the same with the spike-prob as resampling does. Then Lives' cpu-amount decrease drastically. Lets hope it's a fix for this "midi/audio-spike" too, it's obviously another bug - it's too time-consuming working this way!

The next upgrade; 4.0.5 (i'm beta-testing it now) have fixed the bug when deleting miditracks (Live locks up sometimes in 4.0.4) - so that will help a bit!

This is what i've noticed so far - i used Live as my mainhost since the very first release ever.

Good luck solving this!

Regs,
Jo

[supster]

UPDATE:

Ok ... I did install the new dedicated audio drive, and I did see major improvement in zooming, cutting, copying, pasting etc in Arrange view

HOWEVER:

Working with this for a while, I discovered the issue is not gone.

With CPU utilization anywhere over 60% or so:

- zooming becomes sticky and sporadic moreso than I believe is normal

- cutting or copy operations (CTRL-X) can still compeletley LOCK UP live for up to 10 to 15 seconds (!!)

Again, this is not with CPU at a machine taxing 75 - 80% and up.

Yes it is worse with larger loads but it becomes a major hinderance to work (15 second lockups will do that)

Ableton:

Can anyone PLEASE tell me whether or not you believe this is the VIA chipset?

A new m-board and chip will set me back more than I want to spend right now, especially if Im not sure this is the issue?

Theories? please ...

[tylast]

Audio playing while GUI lags is because of the two processing threads, priority seems to be given to the audio engine (as it should be). I still haven't figured out why at about 70% processor load starts to crap out.