slow screen response etc
-
- KVRian
- 855 posts since 3 Mar, 2009
I can confirm, that with a lot of audio files you can get a quite slow system. I never get this with whatever complicated midi only sessions, but have 10 audio files only and things become slower. Have 20+ audio files and things are not that funny anymore. It has nothing to do with the amount of VSTs used. Simply audio files and edited audio files (shorten, copies, etc). You can find those files to practice mixing where they have 10 drum tracks only plus the rest.
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
I never said that there is no slow down when more has to be drawn, especially on larger screens, i know Andreas has a large screen. The more that has to be drawn, the more time it takes, of course. But what Mick was/is saying sounded like something else. Mick also talks about a slow response when clicking on Play. Andreas, do you also have a slow response when clicking on Play when using say 20 audio files? Mick what's your screen resolution?
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
With "transport cursor" you mean the vertical play cursor line, right? Anyway, that observation was about a past version, right? (M3? M4? M5?)
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
To clarify myself: The bigger the screen and the more has to be drawn the more CPU time it takes, that's logical. But that should not be too dramatic (depending on project and machine of course), especially if you keep one core free for UI work, cfr http://www.mutools.com/info/docs/mulab/audio-setup.htmlmutools wrote:I never said that there is no slow down when more has to be drawn, especially on larger screens
Mick some questions:
* Do you have left one core for UI work?
* Is the slow down there from the very first audio part you use? Or is the slow down increasing gradually as more audio parts are there?
* Please make an accurate screen video of the UI slow down when clicking the play button. I still do not know what you're exactly talking about.
-
- KVRist
- Topic Starter
- 180 posts since 19 May, 2009 from UK
Hi Jo
I've tried all combinations of the core options
The slow down is gradual as you add audio
sorry - It's a real pain to make the video - and it's not clear anyway
now you've fixed the timeline problem and have the other stuff in hand - it's just the slow zooming and start delay now that bugs me - it's not massive but about half a second on the project I sent you - but that wouldn't be a particularly big project for me - I often have a lot more audio tracks/takes. I also noticed today that there's a similar delay when selecting a track header!
I've tried all combinations of the core options
The slow down is gradual as you add audio
sorry - It's a real pain to make the video - and it's not clear anyway
now you've fixed the timeline problem and have the other stuff in hand - it's just the slow zooming and start delay now that bugs me - it's not massive but about half a second on the project I sent you - but that wouldn't be a particularly big project for me - I often have a lot more audio tracks/takes. I also noticed today that there's a similar delay when selecting a track header!
Cheers
Mick
Mick
- KVRAF
- 7412 posts since 8 Feb, 2003 from London, UK
Jo, just to ask on this, are there any single click actions that it would be really bad to do if the user were actually making a double click action? Isn't single click usually "select this" (or "focus this") of something and double click "do something to this" - so that performing the single click action would be "okay" anyway? It might make the UI feel more responsive if single click always acted straight away and double click only if the second click came (in the timeout).
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
And it's especially the delay when clicking on the play button that amazes me. I can't find any reason for that. And i can't repeat that in no single case, even not in a bigger session.it's just the slow zooming and start delay now that bugs me
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
I agree there should be no action waiting for a double-click, i always try to avoid that, as a user i don't like a double-click wait myself too. It was the case with clicking the timebar but that has been fixed. If there would be any cases left, let me know. The delays Mick is encountering are not that, as far as i can analyze his feedback. It would be easier to analyze if i could see the problem in an accurate video though. Part of the prob is that in bigger sessions certain actions get a bit slower cause more has to be drawn/processed/... Maybe i can optimize things a bit here and there, but that still doesn't explain the delay he encounters when clicking the play button. Does anyone else encounter that? I just made another test session and no prob. I also can't repeat it using the session Mick sent me.pljones wrote:Jo, just to ask on this, are there any single click actions that it would be really bad to do if the user were actually making a double click action? Isn't single click usually "select this" (or "focus this") of something and double click "do something to this" - so that performing the single click action would be "okay" anyway? It might make the UI feel more responsive if single click always acted straight away and double click only if the second click came (in the timeout).
- KVRAF
- 13865 posts since 24 Jun, 2008 from Europe
Ok after some more testing the very reason has been revealed: Your system needs abnormal much time for opening a file. As you could see in the test results we exchanged your system is more than 10x slower than my test system, which is an average system. There must be a reason on your system. First thing i would suspect is a virus scanner or something like that.
