slow screen response etc

Official support for: mutools.com
RELATED
PRODUCTS

Post

ok thanks - just an idea!
Cheers

Mick

Post

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.

Post

Thanks Andreas - not just me then!! - this doesn't happen any other daws that I use - so I do think I'm right to complain
Cheers

Mick

Post

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?

Post

I'll check the play issue when I'm back home next week.
I clearly recall the transport cursor is slow even with modest sessions, but that's fixed.

Post

With "transport cursor" you mean the vertical play cursor line, right? Anyway, that observation was about a past version, right? (M3? M4? M5?)

Post

Hi

I tried all screen resolutions - makes no difference
Cheers

Mick

Post

mutools wrote:I never said that there is no slow down when more has to be drawn, especially on larger screens
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.html

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.

Post

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!
Cheers

Mick

Post

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).

Post

it's just the slow zooming and start delay now that bugs me
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.

Post

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).
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.

Post

Hi Jo

have just sent another vid - may be a bit clearer?
Cheers

Mick

Post

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.

Post

don't use any such thing - and all other programs nice and snappy

experimenting at the moment
Cheers

Mick

Post Reply

Return to “MuTools”