What is making my DP 9.52 so (swearword) slow ?

[Gone To Lunch]

Even simple things like selecting/deselecting a MIDI track in the tracks window takes up to 30 beachball seconds, while the message 'Transcribing MIDI' with a status bar flashes up half a dozen times or so ?

[magicd]

Transcribing? Do you have the Quickscribe or Notation editor windows open?

Dave

[Gone To Lunch]

Transcribing? Do you have the Quickscribe or Notation editor windows open?

Dave

Yes, I have quickscribe open as I like to edit MIDI notes in a stave view.

[magicd]

Transcribing? Do you have the Quickscribe or Notation editor windows open?

Dave

Yes, I have quickscribe open as I like to edit MIDI notes in a stave view.

How many tracks are displayed in the Quickscribe window? If you use the Track Selector to hide all but the specific track you are working on, does that help?

Dave

[JSmith1234567]

Do you have more than one chunk in the project?

The more chunks you have, the more DP slows down.

[bayswater]

Maybe the Notation editor would work instead of using Quickscribe.

The only time I've had abnormally slow response with DP is with some VIs that by default, preload a very small amount of their samples. The response was due to constant disk access, and solved by maximizing the RAM available to preload samples.

You can see which resource is overtaxed, and by what, by keeping Activity Monitor open while it happens.

[magicd]

Maybe the Notation editor would work instead of using Quickscribe.

The only time I've had abnormally slow response with DP is with some VIs that by default, preload a very small amount of their samples. The response was due to constant disk access, and solved by maximizing the RAM available to preload samples.

You can see which resource is overtaxed, and by what, by keeping Activity Monitor open while it happens.

The notation editor only displays one track at a time, and it doesn't do page formatting, so yes most likely that would make a difference.

Think about it. You have ten different instruments in staves on the QS page. If you edit anything DP has to recalculate and redraw every visible track all the way through the sequence. That's why if you only display a single track in QS (or if you use the Notation editor) you should expect quicker redraw.

Hopefully all this helps and the OP will get back to us with happiness!

Dave

[mikehalloran]

Having certain plugin GUIs open can make DP ridiculously slow. The plug runs fine but having the window open is the problem. If this is your issue, it's easy to test by closing all the GUIs and seeing what happens.

Izotope RX used to be one of those for me. Even now, I'll open the GUI, and make any needed changes or have it 'learn' the noise I'm trying to quash etc. Then I close the window and move on.

[MIDI Life Crisis]

Do you have more than one chunk in the project?

The more chunks you have, the more DP slows down.

Sorry, Smith124567, but i cannot agree with that. I routinely have dozens of chunks with audio, MIDI, and using multiple video files and don't see a slowdown as a result.

It is possible that if you are seeing a slowdown, you might be using the app in an inefficient way. For one, V-Racks will speed up moving from chunk to chunk. Also distributing the load of CPU heavy VIs can be critical in using DP efficiently.

Looking at the o/p's specs, he seems to be on a fairly old cheese grater and using Firewire (which I also use via a FW to TB adapter).

Still, it seems like a fairly reasonable machine with a decent processor and plenty of RAM, so I'd look to hard drives as a possible culprit. Are they all internal? External running on the FW? What is/are his drive(s) for VIs, projects, system? When was the last time he cleared the cache? How full are the drives?

Not that these are his problems, but the assumption that "too many chunks" causes a slowdown is truly preposterous - unless there is some other aspect at work, such as slow drive access or some other unforeseen system issue.

I'd like to see the o/p take one of his problem projects to a clean machine and run it to see if DP is truly the culprit. But as for the "too many chunks claim" it is simply not based in fact, per se.

[bayswater]

The notation editor only displays one track at a time, and it doesn't do page formatting, so yes most likely that would make a difference.

Exactly. Isn't it a matter of using the tools for their intended purpose? I would have thought QuickScribe was not intended primarily as a MIDI editor, but rather to create a score once the editing is done.

[terrybritton]

As mentioned in the Facebook MOTU group, take a look to be certain you do not have a stray MIDI event at bar 4000 or something like that, as such a thing will slow QuickScribe down to a crawl all by itself.

Terry

[FMiguelez]

The notation editor only displays one track at a time, and it doesn't do page formatting, so yes most likely that would make a difference.

Exactly. Isn't it a matter of using the tools for their intended purpose? I would have thought QuickScribe was not intended primarily as a MIDI editor, but rather to create a score once the editing is done.

I sort of agree, but it is also extremely important to be able to see your orchestration and all tracks easily and smoothly as you write and edit. You need to see how the orchestration develops and see the "weight" of the individual lines. You can't really do that unless you can easily see all your tracks at a glance, without DP getting stupid (as if you were using manuscript paper).

I also agree about not showing unnecessary tracks or leave unused editing windows opened. That slows DP a lot.
Sometimes, by mistake, I control click (or is it option-click?) on the track selector, and when I have ALL tracks from my template showing, even if they're empty, this slows DP down to a crawl and becomes unresponsive. Same when this happens in the SE.

Do you have more than one chunk in the project?

The more chunks you have, the more DP slows down.

Sorry, Smith124567, but i cannot agree with that. I routinely have dozens of chunks with audio, MIDI, and using multiple video files and don't see a slowdown as a result.

I agree with your disagreement.

I have dozens of chunks filled with hundreds of tracks, and that's never been a problem at all.
As long as you don't have too many chunks active (i.e., V-Racks) at the same time, DP should remain agile. Normal chunks don't seem to use any resources, since they remain dormant until activated.

What can slow to a crawl are the i/o bundles lists. If you have LOTS of bundles and navigate them through normally, it can take up to a minute to go from top to bottom. Unless, of course, you use the scroll wheel in your mouse for this, and then it becomes instantaneous.

[dewdman42]

The DP10 gui is very slow response for me also.

[magicd]

The notation editor only displays one track at a time, and it doesn't do page formatting, so yes most likely that would make a difference.

Exactly. Isn't it a matter of using the tools for their intended purpose? I would have thought QuickScribe was not intended primarily as a MIDI editor, but rather to create a score once the editing is done.

Yeah but if you put something there that looks like it works, people are going to use it.

I agree that having many chunks in a project is not a problem in general. Switching between chunks can take time depending instruments loading, I/O connections being made, and so on.

I've noticed zero difference in screen redraw between DP9 and DP10. However I'm not using all the new features in 10, such as the scalable windows. I would expect that if you opened a DP9 file in DP 10 without changing anything, the file should work the same way in the new version.

I've used DP since it was installed from wooden floppy disks, so I know the program pretty well. I usually don't have problems, but if I do, my first instinct is to ask what I'm doing wrong. Yesterday I bounced five masters for my band. Four of the bounce files were blank. That's because the Play button was off on those tracks. D'oh.

Reduce the number of displayed tracks in QS and editing should be a lot easier.

Dave

[dewdman42]

I've been away from DP for a while, so please forgive me if I am overlooking something simple in configuration. I pulled it out to do some comparison tests together with Vienna Ensemble Pro 7.

First off, the entire GUI is extremely laggy to use. click the mouse, wait 1-2 seconds for a response...on nearly every action, except the main menubar seems responsive. The Play button seems responsive. But everything else is extremely laggy. It makes me wonder if there is some kind of MIDI loop or something causing it overprocess something in the background, I don't know, but this can't be right. I have to say, if this is normal, then DP is not usable. So let's hope its not normal. But how can I fix it?

Add to that, as I started to build up a 100 track orchestral template (without Vepro), it got laggier and laggier and the Realtime CPU meter started getting larger and larger. Just while sitting there idle DP is consuming 10-20% cpu. Huh? Something must not be setup right, but I'm not sure what.

Any hints?

The configuration is around 100 instrument tracks with ViPro instruments, also each channel has MirPro instance, and one reverb on the main stereo out (maybe that's the issue?), When I look at the plugin performance meter while it's just sitting here idle, every plugin in there is registered as RT and is using some Cpu cycles to sit there doing nothing.

I don't know if that is partially responsible for the GUI lag, but when I try to create a brand new empty project, the GUI is still laggy...not as laggy as 100 tracks, but still laggy and slow to respond, I really hope there is some way to correct that, its hard to believe MOTU would release it like that.