Sign In:     

Forum: VirtualDJ Technical Support

Topic: Xdj az problem deck 1&3 and 2&4
Subject: Urgent Issue: Pitch Fader Jump on Layer Switching (AlphaTheta XDJ-AZ)
​Hi Atomix / VirtualDJ Team,
​I am using the AlphaTheta XDJ-AZ with VirtualDJ Pro (Infinity License).
​I am experiencing a very frustrating issue with the pitch fader when switching between layers (Deck 1 to Deck 3, or Deck 2 to Deck 4).
​Whenever I switch layers, the hardware sends a raw absolute MIDI state dump, causing the software pitch/tempo to jump instantly to the physical fader position.
​I have extensively tried fixing this using VDJScript (pitch_takeover, soft_takeover, conditional scripts, etc.), but all surface scripts fail because the hardware value overrides the software engine before the script executes.
​This makes 4-deck live mixing very difficult. Please update the official native XML definition/driver for the AlphaTheta XDJ-AZ to enforce a driver-level Soft Takeover (Catch-up) on layer switches to block these hardware jumps.
​Looking forward to a fix in the next update.
​Best regards,
Moamen Kwamney
 
Posted Fri 23 Oct 26 @ 11:26 pm
I guess you're using a quite old VirtualDJ build ?
This has been addressed for quite some time.
 
Subject: Re: Pitch Fader Jump Issue on AlphaTheta XDJ-AZ (Latest VDJ Build & Latest Hardware Firmware)

​Hi Support Team,

​Thank you for the quick reply.

​To clarify, I am fully up to date on both hardware and software:

​VirtualDJ Pro: I am running the latest official build with my perpetual Infinity License. ​AlphaTheta XDJ-AZ: My controller is updated to the latest official firmware (Version 2.00).

​Despite being on the latest versions for both the software and hardware, the pitch fader jump / drift issue still occurs on layer switches (e.g., Deck 1 to 3 or Deck 2 to 4), specifically when applying custom VDJScript commands / Shift mappings. The custom XML appears to bypass the native driver-level soft-takeover/catch-up logic.

​Could you please advise on how to maintain custom VDJScript actions while forcing the VirtualDJ engine to keep native driver soft-takeover active on layer changes?

​Please help me get this resolved.

​Best regards,

Moamen Kwamney
 
Subject: Re: Pitch Fader Jump & Drift Issue on AlphaTheta XDJ-AZ - VDJ Engine vs Rekordbox
​Hi Support Team,
​Thank you for your reply. Please let me clarify the situation in a simple way, as this issue is critical for my daily workflow using all 4 Decks on the AlphaTheta XDJ-AZ.
​I have fully updated both my software and hardware:
​VirtualDJ Pro: Updated to the latest official build (Infinity License).
​AlphaTheta XDJ-AZ: Updated to the latest official Firmware 2.00.
​To pinpoint the root cause, I downloaded and tested Rekordbox. In Rekordbox, when switching between layers (e.g., Deck 1 to Deck 3), if I move the pitch fader on Deck 3 to a different position, returning to Deck 1 works perfectly—Deck 1 maintains its original position without any drift until I physically catch up to the value.
​However, in VirtualDJ, when I am on Deck 1 and switch to Deck 3, if I move the slider to a new position and then switch back to Deck 1, Deck 1 instantly grabs the slider's physical position from Deck 3! This causes a strange and sudden pitch/BPM jump.
​As a DJ who relies constantly on using all 4 Decks during live performances on the XDJ-AZ, this jump is very problematic and makes live mixing risky.
​Since my software and firmware are completely up to date, please help me resolve this issue or advise on how to force VirtualDJ to lock/prevent this layer-switch takeover jump.
​I really appreciate your support and urgent help with this.
​Best regards,
Moamen Kwamney
 
Problem xdj az 1&3 2&4 deck Problem please vdj
Subject: URGENT: XDJ-AZ 4-Deck Layer Pitch Jump Issue - Confirmed Hardware Mapping Bug (Comparison with DDJ-RX
​Hi VirtualDJ Support & Development Team,
​I am writing to follow up urgently on my previous inquiry regarding the Pitch Fader / BPM Jump issue when switching layers on the AlphaTheta XDJ-AZ. It has been 4 days without a response, and this issue is severely impacting my professional workflow.
​I want to share crucial testing results that pinpoint the exact root cause:
​Comparative Test with Pioneer DDJ-RX:
I set up my Pioneer DDJ-RX on VirtualDJ Pro and thoroughly tested 4-deck layer switching (moving the pitch faders on Decks 3/4 to different positions, then switching back to Decks 1/2).
​Result: The DDJ-RX performed flawlessly. Deck 1 maintained its original target position without taking over the physical position from Deck 3. Soft Takeover / Pickup worked exactly as intended.
​The XDJ-AZ Behavior:
On the XDJ-AZ (Firmware 2.00, VDJ Pro latest build), as soon as I switch back from Deck 3 to Deck 1, Deck 1 instantly grabs the physical pitch fader position of Deck 3, causing a dangerous and sudden BPM jump during live performance.
​It is extremely disappointing that a flagship, powerful 4-deck system like the AlphaTheta XDJ-AZ is currently rendered unusable beyond 2 Decks on VirtualDJ due to this layer-switch takeover bug. I bought this controller specifically to utilize all 4 Decks in my live events.
​Since this behavior is isolated specifically to the XDJ-AZ, the issue lies in the hardware definition / XML mapping / MIDI response handling for layer switching in VirtualDJ.
​Request:
Please escalate this immediately to the hardware mapping development team to update the XDJ-AZ XML / Mapper definition and fix this soft-takeover bug on layer switching.
​I am ready to test any beta XML mapping or fix you provide. I look forward to your urgent assistance.
​Best regards,
​Moamen Kwamney
 
Mo2mn Kwamney wrote :
It has been 4 days without a response

No, you have received a response. There was a particular workflow that could produce that behavior, that has long been solved.

Mo2mn Kwamney wrote :
and this issue is severely impacting my professional workflow.

A professional workflow also requires a professional license (just saying)

Mo2mn Kwamney wrote :
Request:
Please escalate this immediately to the hardware mapping development team to update the XDJ-AZ XML / Mapper definition and fix this soft-takeover bug on layer switching.

By risking to sound like an a$$h*le (I assure you I'm not :P), I AM the member of the hardware team you are looking for.
I have tested XDJ-AZ (again) and found no issue.
Unless you can come back with a very specific procedure / routine that produces the unwanted behavior (that we can reproduce with the latest official build and mapper) the answer will remain the same:
This has long been addressed and fixed.

Mo2mn Kwamney wrote :
​I am ready to test any beta XML mapping or fix you provide.

That also would require a professional license.
 
Hi,

Thank you for your response. To help clarify the issue and show the exact soft-takeover behavior happening on the XDJ-AZ layer switching during my workflow, would it be possible for me to send you a short video recording demonstrating the exact steps?

Please let me know how I can share the video with you so we can get this sorted out.

Best regards,
Moamen
 
Νο.
You should provide step by step instructions and you should detail each step as needed.

Most of the time people send videos, they assume we are in their brain when they push something or they see something. We are not.

So, try to guide me to reproduce the problem as if I was a 5 years old toddler.
 
Hi VirtualDJ Developers & Support Team,
​First of all, I apologize for any inconvenience or persistence in my previous posts.
​I was previously convinced that the issue was purely a hardware/firmware glitch on the AlphaTheta XDJ-AZ because I had tested multiple custom scripts across other devices (such as the Pioneer DDJ-RX), where everything worked smoothly without any deck crosstalk or fader jumps.
​However, after deep testing and isolation, I realized that this specific script:
​masterdeck ? pitch :
(not smart_play ? pitch :
((beatlock | auto_pitch_lock) ? nothing : pitch))
​is what causes the conflict specifically on the XDJ-AZ. When transitioning/switching control between decks (specifically from Deck 3 to Deck 1), Deck 3 gets affected and causes the pitch layer on Deck 1 to jump unexpected values.
​Because this logic worked fine on other hardware profiles, I kept trying to adjust and modify the script in many different ways to achieve the exact same behavior on the XDJ-AZ, but the XDJ-AZ profile consistently fails with this specific logic structure.
​My Request:
I truly love and rely on this exact logic/behavior for my live workflow, and I thank you deeply for your patience and long support.
​Is there a specific VDJScript syntax, flag, or alternative mapping structure compatible with the AlphaTheta XDJ-AZ bidirectional protocol that achieves this exact same principle and behavior without triggering the fader jump when switching between Deck 3 and Deck 1?
​Thank you for your time and continued help!
​Best regards,
Moamen Kwamney
 
I think you need
- pitch dual instead of just pitch and
-ensure that there's only one "pitch dual" in the entire script, so re-arrange the checks of wether pitch or nothing is used into a single query
 
Ok, now we are getting somewhere.

So, for starters, as Adion said, try to use pitch 'dual' instead of pitch on your script.

Most likely it will work with a simple drop-in replacement.

Otherwise, please tell us what exactly you're trying to achieve with your script above.
I mean, I can read the script and it's conditions, but I can't understand the ending goal of it.
So, let us know and maybe we can adjust the initial script.
 
Hello VirtualDJ Team,

​Thank you very much for your time, dedication, and continuous support.

​I wanted to share a specific hardware-behavior observation regarding a script I'm using, and I would love to get your expert advice on a proper workaround or alternative syntax.

​Here is the exact script I am using:

​masterdeck ? pitch 'dual' :

(auto_pitch_lock ? nothing :

(beatlock ? nothing : pitch 'dual'))

​The Context & Comparison (DDJ-RX vs. XDJ-AZ):

I use this exact logic and script on my DDJ-RX, where it behaves precisely as intended. For example, if Deck 1 is playing at 120 BPM and Deck 3 (paired in dual) is at 140 BPM, and the script evaluates to nothing, I can physically move the hardware pitch fader to match Deck 3's physical position without altering Deck 1's digital tempo. This allows me to manually align the physical fader to prepare for a smooth transition. When I switch back or interact with Deck 1, it understands that the fader movement during nothing was purely physical/mechanical, so it doesn't cause any unwanted digital jumps.

​However, on the XDJ-AZ, a different behavior occurs due to how the hardware/XML mapping handles state-syncing after returning from the nothing state—resulting in a sudden digital snap or catch-up upon returning to the deck.

​Since the logic itself is sound and runs seamlessly on the RX, could you please advise on what alternative script syntax or structural adjustment I should use for the XDJ-AZ? My goal is to keep this exact workflow (where the fader can be moved physically during nothing without affecting the digital value until re-engaged), tailored specifically to how the XDJ-AZ handles MIDI/hardware state tracking.

​Thank you so much for your guidance and help!"
 
I will have to understand exactly what you want to achieve.
Otherwise it doesn't matter what your script was (since it won't work with AZ)
Also please respond to my questions, as a normal human being. Not through an AI curated message.
That's if you really want me to help you.
I will try to figure out what you want, and I will try to find a solution for you.
But I need you to respond better to my questions. And I will also need some time.
Thank you
 
First of all, I am so sorry for using an AI to translate and write my messages—my English isn't strong enough to explain this technically, so I really appreciate your patience!

​Let me explain the exact script and what I am trying to achieve. Here is the script I am using:

​masterdeck ? pitch :

(not smart_play ? pitch :

((beatlock | auto_pitch_lock) ? nothing : pitch))

​The Goal:

On my old DDJ-RX (which is also a 4-channel controller), this script worked to absolute perfection across all 4 decks, and I am heavily used to this exact workflow. The goal is to make the Master Deck the sole controller of the pitch fader. Any non-master deck is frozen/ignored (nothing) and its slider won't affect the software unless it becomes the Master Deck.

​The Problem on the XDJ-AZ:

​On the XDJ-AZ, this script works great and perfectly on Decks 1 and 2. ​But when I go to Deck 3 or 4, and move the physical fader (while digitally/software-wise the pitch wasn't touched and it stayed as nothing), when I return back to Deck 1, Deck 1 suddenly jumps and adopts the physical position of Deck 3 — even though Deck 3 never changed digitally in VDJ at all!

​Since this behavior worked successfully on all 4 channels on the DDJ-RX, how can we adjust or fix this script so it maintains the exact same logic and behavior on the 4 decks of the XDJ-AZ?"
 
What's the purpose of not smart_play part of the script ?
Also you have provided different scripts before.
So, which one is the exact one you're using ?
 
"Thanks for your help! Let me answer your questions:

​The purpose of not smart_play: The purpose is to act as an on/off switch for the script based on Smart Play. If Smart Play is turned on for that deck, the script applies its rules (as written). But if Smart Play is turned off on that deck, the script doesn't apply to it at all, and the pitch slider remains completely free and normal. ​The exact script I am using is: masterdeck ? pitch : (not smart_play ? pitch : ((beatlock | auto_pitch_lock) ? nothing : pitch))

​That is the exact and only script I am testing on my XDJ-AZ right now. As I explained, it works perfectly on Decks 1 and 2, but when I move the physical fader on Decks 3 or 4 while it's returning nothing, going back to Deck 1 causes it to jump to that physical position. How can we fix this while keeping this exact script logic?"
 
I'm asking because I need to understand the end goal.

smart_play by itself is a toggle that controls what happens when you press the play button, and therefore under normal circumstances it should be irrelevant to pitch control.

Your current script will NOT work with XDJ-AZ "as is"
You need to accept that.
We need to find a similar script, or a script that's close enough to what you want your controller to do (not what the current script does)
We don't have control over the XDJ-AZ firmware and we cannot prevent it from doing things differently than your DDJ-RX. Therefore we can only alter the script.

Finally as I said, I will need some time. Once I get 100% what you're after (I think I did) I'll have to make a script and then also test it on the actual device.
However keep in mind that I work with several controllers and I don't have all of them easily accessible on my desk.
So, be patient and I will have something for you to test soon.
 
"Thank you very much, my friend PhantomDeejay! I really appreciate your understanding and that you finally got the full picture of what I am trying to achieve.

​Just to briefly clarify one thing about how Rekordbox handles this compared to my setup:

In Rekordbox, this behavior follows the Sync state. But here in VirtualDJ, because of how instant-sync works, I designed my script to follow the Smart Play state instead. This means: if Smart Play is active on a deck, the script applies its rules; if Smart Play is turned off on that deck, the slider becomes completely free and normal.

​I completely understand that matching native software behavior isn't always easy, but I really hope we can achieve this workflow on VirtualDJ with the XDJ-AZ.

​Thank you a million times over for your time, patience, and support. Take all the time you need, and I will gladly wait for whatever script you come up with to test it out.

​Thanks again!"