Recently upgraded to 6.06. Have troubles with hitpoint detection. Using the hitpoints to detect hits on my snare track, then creating a midi channel based on those hitpoints.
More than 50% of the hitpoints are coming in too early, with no audible or visible reason for where they’re being placed. I’ve tried deleting all hitpoints and detecting again, but no luck. Also tried with different threshold settings, but none of the hitpoints will actually move. I know they can be moved manually, but this project has sessions lasting 6 minutes and over, and the idea of moving all the snare hitpoints by hand doesn’t seem appealing.
I will attach a snapshot I took of the problem. I’ve used hitpoint detection several times before and never had this problem, which was before the 6.06 update if that means anything. Also, in this pic, the threshold is not set in any particular place. I had already tried different threshold places and re-detecting by this time.
This happens to me to, usually not as bad as you are experiencing but enough to make it annoying and time consuming.
We really need some tweakable parameters so we can customise the detection algorithm to fine tune the response.
In the meantime it may be possible to use offline processing on the snare track, ie some eq to tune the track for a better response, like some HP filtering and maybe a little narrow boost at the peak frequency to give the hit point algorithm a better chance of detecting the start point, then once done use the offline undo.
IME this happens mostly where the tail of one hit runs into the next…which is what your screenshot is showing.
(Bad spill could also cause it)
There is a workaround: Copy the track & noise gate it from the process menu
Set the attack & release to 0 & min opening time to something like 20ms, adjust threshold to remove the tails of the snares that are interfering with the detection. Just make sure you don’t completely remove any low level hits.