Hitpoint Detection in C10.0.20 is fixed and works better now. It is not as accurate as in Logic or Pro Tools but better than before the update.
Unfortunately, the new intensity slider does not change the partially incorrect positioning of the hitpoints! Problem not solved!
It seems better in 10.0.20 to me…
Sigh… as I suspected; no underlying improvement to the actual Hitpoint Detection algorithm. This ‘Intensity slider’ business I can imagine is a fruitless task - if it hasn’t got the hitpoints placed correctly, first.! No amount of fiddling with that will improve things.
So, he did say…
Could you maybe send him that one @Norbendo.?
He can use any recorded drums, it will not work correctly. Sorry Steinberg, this is not “pro”!
For me 10.0.20 fixed the issue with hitpoit placement. Now it’s seems to be the same as in earlier verions.
But I still can’t lock multiple hitpoints at once (shiff+alt). It says “lock multiple hitpoints” but won’t actually do it. In previous verions it works just fine.
Anyone have the same problem or I’m doing something wrong?
As far as I am concerned Hitpoint Detection in Cubase is subpar. It is OK for slicing up drum parts with some editing required, but not accurate enough for automatic drum sample replacement (hitpoints to midi function). Not even close for accurate manipulation of non-percussive audio. This latest update seems to have gotten it back to C9 accuracy although some say not? Either way not up to the level needed in a modern DAW.
Please can you post an example file or two of what you mean/expect.?
And yes, also seeing mixed reports on this for v10.0.20 from a few users. Not exactly confidence building…
Am not updating just yet, so can’t check myself.
Not updating here as well. Still waiting…
Just an idea: Is this bug probably sample rate dependent?
Mentioned this before (somewhere else) that perhaps the calculation percision, audio buffer, bit rate, sample rate and file format may imapct HPD? It was once discovered that automation was less accurate with high buffer size…
BUT: I wonder why Steinberg could not figure this out by themselfes?
Folks, just read through this whole thread and got me thinking that it may be related to another bug that’s been driving me nuts since 9.0 - tempo detection.
With that bug, tempo detection only works at 44.1k. At any other sample rate it catastrophically freezes.
Though asked above in passing, I’d be interested to know if the hit point problems are only occurring in projects that are not 44.1k? What rates are you using?
I am using 44.1 always, and you can see my results above at the screenshot I posted. But yeah, I really cannot understand either why Steinberg cannot find out these issues by themselves.
Based on your signature, you have a system that exceeds the standards required to run Cubase at a good level of computer performance. How far are we expected to go with the machine side to get an “adequate” DAW box to work with? And what was all the hype about the new 64 bit system and all that? Where is it? After 30 years of development, one would think hitpoint detection would be nailed and users would flock to the program because of how easy it was to cut to hit points in Cubase.
I can totally hear your frustration guys, but may I suggest the following: If you don’t like paid-for beta software, then simply don’t use it until it’s fixed. I other words: change yourself. Steinberg is not going to, why would they otherwise pull off such bs in the first place.
I do wish transient points could be an imbedded standard that could be cross platform. I guess there might be a way around this by creating a Rex file or something similar but not the same thing really.
Still Broken in 10.5