I am using a Rane One with 5.2.1. My problem is simple, but infuriating:
If I disable an autoloop close to the end of the loop, the track will still loop back to the beginning of the loop. I have already disabled the “always quantize loops to beat” option. “Quantize cue/loop” is also disabled.
Hi @Fangio, when creating new topics, please do not forget to answer the questions in our template with specific details about your setup not just “iPad” or “Latest Version”. This helps all of our community moderators to provide the most effective support to users with the utmost efficiency. Thanks!
Device Model (ex. 2020 iPad Air 4th Gen): Version of operating system (ex. iOS 17.3.1): Version of djay (ex. 5.1.3): Hardware/controllers used (ex. Reloop Ready): Hardware Firmware Version (ex. 2.7):
Also, can you please try to capture a video of this, upload it to your Google Drive/Dropbox, enable sharing permissions, then share a link to the video here? As I don’t currently have access to a RANE One, I’ll need to share this with engineering to see if they can replicate it. Thanks!
Device Model M1 Macbook Air Version of operating system Sonoma 14.5 Version of djay 5.2.1
In the attached video, I am going to demonstrate two issues, both of which seem to be software-based and related.
First, you will see me activate a loop, then cancel the loop slightly before the end. You will see the loop reset back to the beginning regardless.
Second, you will see me attempt to tighten a loop down from 4 to 1/8. You will see that once it gets down to 1/4, it appears to take the software an extra loop to realize the change.
Please pay close attention to the mouse and when I am clicking in the video. I understand that issue #2 could be up for debate as I am cancelling/modifying the loop right at the end, but I absolutely cannot see how issue #1 makes sense as I am cancelling the loop before the end. Note that it doesn’t seem to matter whether the loops are quantized or not.
Hi @Fangio, thanks for the additional details and video. This is very helpful. I’ve passed this onto engineering for review. I’ll report back when I have news. Thanks!
Aha! This appears to be precisely the issue. With key lock ON, I notice the mentioned bug, as well as various other critical delays (e.g. non-instant response time when using beat jump as well as when bringing stems in/out). With key lock OFF, at least after a few minutes of testing, none of this delay/lag is noticeable.
Thanks for confirming @Fangio. This is a known performance limitation when using Key Lock. Engineering is investigating options for improving this latency when using Key Lock, but for now it’s about 100ms.
Ok I’ll stay tuned. I’m sure you’ll agree that the delay is pretty much unacceptable from a usability standpoint for any complex routines/mixes which use the affected features. As well as from a performance comparison standpoint vs. Serato for example.
Hi @phuongtastic, I’m just following up on my question above from a week ago. You’re response was unclear. Please confirm that you only experience this issue with Keylock ON. Thanks!
Hey, just checking in on any progress in this area? The latency with key lock on touches pretty much all the features I need to use regularly (loops, beat jump, stems), and thus makes the experience very frustrating and borderline unusable in certain situations.
Hi @Fangio, thanks for the follow up. Our engineering team is still investigating options here, but we don’t have any updates to share at the moment. I will report back here when I have news though. Thanks again!