Hitpoint Best Practices

Correct me if I’m wrong, but Cubase calculates hitpoints often starting at the very first onset of a transient. For instruments with very slow, long waveforms (kick drums and bass guitars), it can kinda take a second for the transient to reach its peak from the initial onset. After quantizing with hitpoints in the default location (or close to it), these instruments are often feeling a bit awkwardly late. I suspect this might be why.

So, what gives? Is it best practice to move hitpoints to the peak of the transient? If so, is there a way to make Cubase aim for putting the hitpoints there rather than the beginning of the transient so you don’t have to edit EVERY. SINGLE. ONE.

Asking for a friend…

…and that friend is me. Asking for me :blush:

Would changing the hitpoint threshold achieve the result you’re after?

Thanks for the reply!

Unfortunately, it doesn’t. The threshold just changes the volume minimum level a transient needs to cross before the hitpoint detection algorithm creates a hitpoint for it. It doesn’t change where that hitpoint is placed in time.

I have the same issue as the OP, but with C13. Is there any way to get proper hitpoints? Often enough, they are set all over the place. We need a way tho adjust this!

Now this looks very odd. Can you share a snippet of this particular audio file (or maybe you used a file from the Cubase stock content)?
I’d like to see if the hitpoints are equally off on my computer.

Odd indeed, and this is not even the worst scenario. I’d like to give you the snippet, but right now Cubase refuses to start at all! I am so sick of this unreliable piece of s…(oftware).

EDIT: Okay, here it is. This screenshot is from the same file. With this “precision” on hitpoints, I end up adjusting them manually, which is not what I paid a small fortune for (over the years). At least in my opinion.
Sample File 1.wav.zip (458.1 KB)

1 Like

Hi, @wotar

I looked more closely at your sample file. indeed, it seems that there is an issue with the hitpoints detection algorithm (HDA), in your case. Few screenshots of it :

Overall Zoom Full aspect

A closer look of the third hitpoint...

... to a sample level.

This seems to show that there something not actually relevent that triggers the HDA at the wrong place.

Beside this, I have tried a lot of possible combinations of the three Threshold, Intensity and Minimum Lengths parameters : no matter the one involved, I can make some hitpoints disappear and reappear, but none of them are moved in a more relevent place. I even tried to disable the ASIO Guard as, at a point, I thought that maybe the double buffering could be involved, a way or another. Actually, nope…

I think that there is something fishy in the HDA that shows its ugly head with a case such as yours. This said, I never went to stumble on such a problematic hitpoints detection result, until now… :thinking:

2 Likes

So should this be brought to the attention of Steinberg now? What do you think?

Yep, but it would be better to have other confirmations on the HDA misbehaving from other forumers first. From which, I don’t want to tag this thread with an issue one yet, as the recently reported issue is not from the OP - the initial post being more than four years old and not exactly related to the subject.

The best would be to split this thread as two, the most recent one getting a title better suited to the issue. Then it could be tagged as so.

@steve ? :pray:

This has been reported to Steinberg.

2 Likes

Thanks for diving in! Your results look familiar to me. :wink:

Honestly, I never thought it would work this way. As the manual says, Intensity and Threshold are just filters. All I’ve ever experienced is HP’s appearing and disappearing exactly as you describe. I’d love it if we could set the position of all generated HP’s to be somewhere between the very first and the most intense transients of the signals.

1 Like

Yep, I have not written this accurately : I already knew that and when playing with these two, I was actually hoping to see other hitpoints appear at more “convenient” places (IOW, at the beginning of an attack, or at least in front of significant level changes). Actually, just one is added when setting both to 0%. But, looking more closely at the Operation Manual (Cubase pro 14.0.0 PDF version, p.617) :

C14-0-0_OM_p617

…nowhere it is mentioned that it should work differently than it does. After this, all depends of the meaning of “relevant positions” and maybe our expectations aren’t as so.

I often use hitpoints and warp markers to slightly correct my guitar playing which, too often, isn’t very accurate, time related, and usually the HDA does a good job with such a material. :neutral_face:

For softer material this may work. However, to quantize my short signals strictly to the grid (I want them to be spot-on), Cubase’s hitpoint detection as it is does not seem suitable. I need something more accurate (and flexible). Maybe someone can recommend an audio editor that does a decent job in this regard?

On every new release of cubase , I go directly to the hitpoints to see if they have been improved, and they always remain the same . Wildly inaccurate . This has been the case for years . When will this be addressed and fixed ?