Experienced an annoying “feature” called “Drag Delay” which is supposed to minimize the risk of moving parts accidently buy delaying the dragging action. When i turned to the manual I was relieved to see that you could turn it off. However, changing the delay time in the Edit part of preferences does absolutely nothing. Can anyone confirm this?
I run Cubase 6.0.3 for Mac.
I reported the same issue back in C5. There was a thread in the old forum where SB concluded with “Everybody will agree that “drag delay” is working.”. Have a read:
R
This is still broken in C6.
If the mouse pointer is stationary while the button is pressed, and then you try to move the object, then the delay does work. But if the pointer is moving while the button is pressed, the object moves immediately with no delay
This is a shame, because presumably the purpose of “drag delay” is to prevent accidental dragging, and it doesn’t always do that. Most of my “accidental drags” fall into this second category (accidental click while mouse is moving)
To repro this, set drag delay to 500ms and try moving the mouse pointer rapidly around over some events while clicking the button randomly. The events get dragged all over the place, with no delay being implemented.
Omg, didn’t know that it had been addressed before. Probably because I didn’t have any problems in previous versions (PC back then). Now it seems as though the drag delay is constantly set to max. It doesn’t matter what number I type in the settings. And, yes, the delay works as intended when the mouse is stationary, but not when moving the mouse, as addressed by FunkyDrummer. However, the settings for it doesn’t work if you DON’T want the feature at all it’s still impossible to turn it off…
This is definitely a bug, and I’m stunned that Steinberg says it works as intended! Do they not listen to the users? I want to be able to turn this “feature” off, or at least lower it considerably. For me, working with small parts and small changes all the time, this has made the program practically unusable. Please SB, have a look at this before next patch.
The Steinberg didn’t speak. Me and other members of this userbase where talking about this in that thread. Right in the middle after my last post the forums where switched and the discussion was not picked up here. Now it is picked up. Post a repro if there is a bug to report.
This is how to report a bug:
How do I report a problem with Cubase
Gr,
JHP
This is definitely a bug, and I’m stunned that Steinberg says it works as intended! Do they not listen to the users? I want to be able to turn this “feature” off, or at least lower it considerably. For me, working with small parts and small changes all the time, this has made the program practically unusable. Please SB, have a look at this before next patch.
It’s wise not to make empirical statements. How many users do they need to listen to? If youre working with small parts and small changes you will be a minority even if that work is important like editing historical recordings and suchlike but most users use it for general day-to-day recording so the drag delay defualt of 200ms will work for most, as it does for me and I move the odd small parts around without much incident that I have noticed. The recording edits that I sometimes do I can execute very rapidly and accurately.
I’m really just trying to point out why you may feel ignored by the devs because, like a spot on your face, any small and seemingly insignificant bug can seem the size of Jupiter but the devs just see a flea on their pet carthorse.
If the program is unworkable for you it may be wise to work with one that is more friendly to your work practises.
Maybe what you have here is a new idea for the way drag delay works. I’m wondering if the drag delay is working but just not the right way for you. But it could be it joins the oddities like some of the metronome and Tempo page settings etc. Somehow a little unfinished but because there’s not too much of an outcry they’re left to gather dust in the corner.
Repro:
I’m not sure how many milliseconds duration the quickest of mouse taps is, probably around 20 ms or so. But definitely less than 500ms!
This feature refers to the time detected from when a drag starts - its nothing to do with the amount of time the mouse button is pressed. Isn’t it…?
At least thats what I always thought - though I have been known to be wrong on more than one occasion. 
When does the drag start then, if not when the button is pressed?
How else can the computer know you are dragging, except when you press the mouse button down?
You have to start the clock running at some point… when?
The purpose of drag delay is to prevent accidental dragging. That is not in dispute.
But I am saying the cubase implementation of this does not work properly when the pointer is already in motion - only when it is stationary when the button is depressed. Try it and see.
Not at my music machine just now…
Ok FD understood; got your point. Maybe I have misunderstood.
So, re-read the thread.
Back to your post, 3rd one in - I see you say this feature is working as you’d expect from the viewpoint of a stationary cursor (and that’s where I was coming from; and what I would like to add here is that I believe the ‘clock starts running’ the moment the program detects that a drag is being attempted - nothing to do with how long a mouse click is pressed and held stationary over an event).
The concern you raise here, is for when you click and the pointer is already in motion… Hmm…
I will keep in mind and have a play when back at my machine.
Why would anyone want to tap the button repeatedly? Or have I done it wrong all these years?
The simplest way to avoid a few weeks programming is to keep the button pressed down. Very easy unless one has delirium tremens.
As you can see from my avatar I suffer from this and my left handed three button mouse has escaped.
So no tea for me tonight. 
Yes indeed haha this is just a way to force it to happen in a short time.
In reality, it happens randomly.
My point is that Steinberg so surely claims that the function is working as intended and then leaves the discussion. If working as intended, users (me and others) clearly don’t seem to understand how. From my point of view it’s pretty simple, I see an option to set a value between 0 to 500 ms (as stated in the manual), and changing it does nothing what so ever. Setting it to 0 should mean instant dragging, but the waveform or midi-part freezes for some time before moving when I try to drag it, which dramatically slows down my work. As it was working for me in 5.5 I will try to roll back and pray that it still does…
It worked ok in C4 but then it was shafted in C5. Here’s someone in 2009 with the same problem
The Drag Delay value does not function
1a. Set C6 to Preferences–> Editing–> DragDelay–> 2ms
1b. Set SX3 to Preferences–> Editing–> DragDelay–> 2ms
2a. In C6 Click on event with non moving mouse → move mouse to start drag
2b. In SX3 Click on event with non moving mouse → move mouse to start drag
3a. Set C6 to Preferences–> Editing–> DragDelay–> 500ms
3b. Set SX3 to Preferences–> Editing–> DragDelay–> 500ms
4a. In C6 Click on event with non moving mouse → move mouse to start drag
4b. In SX3 Click on event with non moving mouse → move mouse to start drag
1a. Set C6 to Preferences–> Editing–> DragDelay–> 2ms
1b. Set SX3 to Preferences–> Editing–> DragDelay–> 2ms
2a. In C6 Catch part during mouse movement, Move mouse over event–> click and continue to move to drag
2b. In SX3 Catch part during mouse movement, Move mouse over event–> click and continue to move to drag
3a. Set C6 to Preferences–> Editing–> DragDelay–> 500ms
3b. Set SX3 to Preferences–> Editing–> DragDelay–> 500ms
Problem:
The Drag Delay value does not function as in older versions and some users accidentally move there events.
Workaround:
When moving an event to a location that you do not like, press Control+Z to undo this move.
Animated gif illustrates repro:
Status, Comments
Confirmed, Cubase 6.0.3 Build 345
Original Report Topic
(29316)
Thanks for looking into this JHP,
In the GIF you recorded, for “Test 2” (moving mouse scenario) I notice that you are keeping the mouse button pressed for a fairly long time. I can see this because of the circle that appears round the mouse pointer. When you hold the button down for as long as you do in the video (which seems approx 500ms), then yes of course I would expect the event to be dragged.
What I think is important for you to understand about the moving mouse scenario, is that Cubase allows objects to be dragged with only a very very short button press. A very short tap on the button will do it, as if the button is red hot. Even with drag delay set at 500ms, the event will still be dragged immediately, with no visible delay, (500ms should be very visible). In my experience, most of my “accidental clicks” are of very short duration… I am sure I’m not alone in this experience.
Just wanted to point it out, in case it got lost in translation somewhere.
Cheers
Could it be that the adjustment is meant to compensate for different mouse characteristics rather than a dragging style of working?
Could be that it’s “out of date” (?) because mice seem to be pretty much the same these days?
Mind you, I need to refresh my reading of the manual on this. Just maybe an idea of why it is like it is.
Thanks alot JHP! This clearly shows that something is wrong. For me though it doesn’t matter how rapidly the mouse button is released - the part still moves with the cursor, so the accidental move prevention is completely malfunctioning. The strange thing is that it will still take a moment for the part to move, regardless of what value I put in the drag delay parameter.
It almost seems as though the drag delay value sets a randomized number during installation, which is why I experience different delay in my different installations, and then stays that way. 
In Preferences–> Editing–> Drag Delay click on help and it states about this function:
With other words there is a time variable needed that differs between a selection and a drag.
As we can see, one user is having problems with the drag delay preference slowing him down and he would like to reduce the drag delay time. This user is a Mac user:
The other user is having problems with unintentionally moving parts and would like to increase the drag delay value because of accidental clicks while moving the mouse:–>
There is a difference to this behavior between PC and MAC.
Many users do not have a problem with the current select and drag n’ drop behavior.
Gr,
JHP