Whenever I do live recording and use the pads, it seems like no matter how hard i try to hit the start of bar 1, my first notes always begin at the end of the pattern. This happens even when I use the 16th note quantization. Does the sequencer for some reason prioritize placing the notes played at the end of the pattern rather beginning at bar 1? or maybe I just always play early. that could be it. but i noticed this and specifically spent a few rounds trying to get it to trigger after beat 1 but it wouldn’t happen.
additionally, once that note is placed at the very end of the pattern , i can’t simply move it forward to beat 1 of bar 1. When i grab the column and shift it, it won’t go to bar 1, even when I adjust the U time to 0. I can cut and paste it, but it then the whole rhythm of the cords are messed up. it is kind of annoying have to work with a progression when the start of the 1st cord is at the end of the pattern.
Edit: shout out to @polynil for letting me know that i need to shift the U past 100 to get to beat 1,
I think a more coarser quantizatjon is needed. 1/16 is really a pain.
i wanted to get my thoughts out there and see if anyone can relate. absolutely love this machine though. it’s insane.
edit: sorry for spelling chord wrong over and over haven’t sleep for awhile too busy
Are you monitoring the sound of your instrument through your DAW?
This could be the cause: when there is latency between pressing a note and hearing the audio, your brain automatically adjusts for that: you will play earlier to make the audio sync to the beat.
Try to use direct monitoring without latency. If your audio interface doesn’t have a direct monitoring option, you can use headphones plugged into the instrument and turn off the monitoring in your DAW.
Yes now that I think about it, this must be it. Unfortunately direct monitoring won’t always be an option because I like to use effects that I route through ableton. Seems that no matter what I try to do, there is always some major shortcoming to my setup lol. dang it. thought I had a good configuration figured out finally.
Also, try using the “reduce latency when monitoring” feature. This will disable added latency caused by plugin latency compensation for the track you are monitoring.
Squarp is also planning to add midi/clock shift features for Hapax, so that might help in the future as well.
Maybe you can also send a feature request to Squarp for a function to add for latency compensation in midi recording, so it will actually add some latency to align your recording to the grid again?
@Maarten
All great suggestions. thanks for the advice. I am always trying to get the best worlds of hardware (for creative fun) and software (for ease of recording). Well i’ll get there someday.
I’m using direct monitoring and regularly run into this issue as well. I also blame my bad timing but then again, when I record midi in Logic this seems to happen to me far less often. Could still be me, of course.
What works on Hapax is moving the notes’ uTime to the right (past 100%). They will reappear on step 1.
omg thank you for that tip I would have never thought to move the U to the right past 100. Going to save me a lot of trouble. and knowing that you experience this as well, I wonder if there is something to it or if we are just always early. i’ll try more this weekend.
So I did this test and it does record correctly. I sent clock from my Hapax to the TR-8S and sent midi notes back from my TR-8S to the Hapax and it was recorded on the grid, with just a little bit of latency (uTiming: 4%), which is to be expected.
So it must be your brain compensating to the audio latency
@Maarten
good test and certainly checks off most boxes but i do wonder if the processing of notes is different when entered via pads vs externally. probably not but that is my final remaining question considering your test. also i mainly noticed this while using the chord track type.
OK. So I’m not a robot, so I can’t perfectly time the pads I’m hitting.
However, I did a little test:
I made my Hapax send a midi metronome to my TR-8S (using the open and closed hihats as metronome).
Then I lowered the level of my kick drum, so I couldn’t hear it when I hit a pad to trigger a kick drum. This way, my brain can’t compensate for any audio latency, as there is no audio. I only hear the mechanical sound of the Hapax pad when I hit it.
So I recorded several bars of 4-to-the-floor kick drums. I did the same with a polyphonic synth with the Chord mode (single chord on each down beat). Then I raised the level to listen and looked at the recorded notes. The timing was pretty much exactly how I expected it to be. So sometimes I noticed I was lagging behind with hitting the pads and then the recording also showed the notes were recorded late.
When I though to have recorded a bar pretty accurately (judging by my ears - listening to the mechanical sound of the pads), I stopped recording and looked at those recorded notes. They were pretty spot on. In fact, it happened more often that the notes were a bit late, than that they were early.
Of course, this is not really scientific, but I think this is the best way I can test it at the moment. And I am also a vinyl DJ, so I am used to beatmatching by ear, so I think I can trust my ears. So I am fairly sure Hapax does record (very close to) exactly how you play the pads.
Wow thank you for the in depth testing you did. Very smart and thorough approach. That definitely puts my mind at ease. I hope you got something out of it as well!
One notable difference between Hapax pads and external gear is the inherent lag of external gear, which simply is not there with the internal pads and that WILL produce slightly different timing. The more complex MIDI processing/routing you have in between the external keyboard and the Hapax, the bigger the difference. And if/when you’re intuitively compensating for the lag of the external gear, you’ll be early when the lag is not there. As with the pads.
So, one thing that I didn’t know for a while is that regardless of your quantization, the Hapax will record “microtiming”, which can pretty much nullify your quantization settings. In step view, hold “all” and you would see that there is a non-zero value of some range in uTIME. While holding “all”, click the uTIME encoder and hold for a second to erase the microtiming.
that is strange to me. so quantize only applies as expected if the U time = zero? is that what you are saying? that would be good to know. kind of weird because you can have quantize on during recording and after but in reality nothing is quantized if you have a U value?
The quantize function is non-destructive. Meaning: it is applied after the recording. So the notes are recorded as they are played and can also be turned off afterwards. The notes are also shown in step mode how they are recorded (unquantized). But upon playback, they are quantized.
The trick with resetting microtiming to all notes will actually shift the notes, so the end point will also shift. This is not really quantizing. I really hope Squarp will add a destructive quantize option as well, so you can quantize the starting points of the notes without shifting the end points.
