Normalize Bug

Was normalizing a closed hi hat sound today and after clicking ‘ok’ to normalize the file corrupted.

dunno if its helpful to post the file, but its a short sample. It was recorded at 26khz in case that matters as well.The sound was assigned to pad D3, and it seems like memory corruption also occurred as pads 4, 5, and 6 stopped playing when I tapped them. I was able to re-assign the same sound to the pad and it started playing again.

so far not reproduce-able but will post back if I find a recipe.

3 Likes

Was just about to post about normalize! Any time I’ve hit normalize it works in the moment, but when I back out of the loop/slice screen it goes back to the original volume. Have you encountered that issue Craig?

1 Like

Yes- It fooled me at first, but here’s the trick:

normalize the sound, go to save -> overwrite same file right after normalizing and it keeps your normalization. If you tap a different pad, it seems to either reload or throw away the normalized buffer.
See if that works for you.

1 Like

Did you have the same sound assigned to pads 3, 4, 5, and 6?

I did not. Also The sound that corrupted was a closed hi-hat sample on pad 3. The next pad over was an open hi hat, and then a low tom, high tom. Each pad would display the correct waveform, just would not play when you tapped the pad. Corrupted pad was 3. 4, 5 and 6 would not play, but then 7 and 8 would play. I also noticed that the ‘playhead line’ was not scrolling across the sample when it was in that state either.

All right. I was having the same too.
Thanks!

1 Like

I would have a similar problem with sounds not playing. Turns out I moved the slice point. It had to be moved back the beginning of the sample. Not sure if it’s a bug or if did it. Hitting to many buttons hope this helps.

1 Like

you may have moved a fader.
You can lock them… :wink:

3 Likes

Oh so 1that’s what fader lock is all about. Duh :man_facepalming: