dJdAb
Just curious, is there a way to view / edit built-in definition files? I'm wanting to edit very specific data being sent to Rane One controller and mapping won't cover it. I want individual deck data not global / self-assignment, like it's written.
Specifically, I'm wanting to send deck 3/4 pitch slider movements to control Rane One platters (which currently only respond to deck 1/2 out). "invert_deck" kinda get's me there, concerning internal pitch slider data to controller platters but I lose everything else (layout / buttons). Now, if you're curious, why I would do this well... see picture ;o)
Thanks, Sean
Specifically, I'm wanting to send deck 3/4 pitch slider movements to control Rane One platters (which currently only respond to deck 1/2 out). "invert_deck" kinda get's me there, concerning internal pitch slider data to controller platters but I lose everything else (layout / buttons). Now, if you're curious, why I would do this well... see picture ;o)
Thanks, Sean
geposted Mon 27 Sep 21 @ 7:24 pm
dJdAb
Also how do you isolate just one button / slider when it's mirrored on deck 1 / 2? Let's say I want pitch slider on deck 1 to be seen by mapper as "pitch 1" and pitch slider on deck 2 as "pitch 2" instead of both being just "pitch" as assigned by definition file. I'd really like to edit that.
Also, found a glitch with the definition file, as it sits now. When selecting line-in on the Rane One, the contour is flipped on the up/down volume. So, a smooth fade (internal player) now becomes harsh fade (external player). The only way around this is to spin the contour knob the full opposite direction every time. I'm sure someone just got something backward or forgot to invert something.
Also, found a glitch with the definition file, as it sits now. When selecting line-in on the Rane One, the contour is flipped on the up/down volume. So, a smooth fade (internal player) now becomes harsh fade (external player). The only way around this is to spin the contour knob the full opposite direction every time. I'm sure someone just got something backward or forgot to invert something.
geposted Mon 27 Sep 21 @ 8:03 pm
dJdAb
Forget it, using “action_deck” commands
geposted Tue 28 Sep 21 @ 5:50 pm
PhantomDeejay
Besides the fact that internal definitions are disclosed information, even if you had access to it you would not be able to do what you want the way you expect it.
First of all there's a firmware in place that likes certain things and doesn't like others.
For instance you see "one" motor/platter on the left side, but this motor is controlled by 2 different messages (one for each deck). So, it's one motor with two layers for communication. The firmware expects that while the motor is assigned to one deck (layer) it won't receive messages from the other layer. Failing to do so, results on strange behavior. The motor does not reject nor accepts the messages from the other layer. It behaves unpredictably because the firmware lacks the code to handle such situation.
What I'm trying to say is that motorized decks like Rane Twelve, Twelve MKII and One are too way complex units, with a way too complex firmware. You need to perform things the way the device (firmware) expects them and not freely.
So, even if you had access to the internal definition of the device, you would still struggle to overcome the firmware limitations and expectations.
In other words, if you want to be safe, try to achieve the best you can via remapping. The communication part with the device is already taken care by VirtualDJ and it's internal definition and it's compliant with the device firmware.
First of all there's a firmware in place that likes certain things and doesn't like others.
For instance you see "one" motor/platter on the left side, but this motor is controlled by 2 different messages (one for each deck). So, it's one motor with two layers for communication. The firmware expects that while the motor is assigned to one deck (layer) it won't receive messages from the other layer. Failing to do so, results on strange behavior. The motor does not reject nor accepts the messages from the other layer. It behaves unpredictably because the firmware lacks the code to handle such situation.
What I'm trying to say is that motorized decks like Rane Twelve, Twelve MKII and One are too way complex units, with a way too complex firmware. You need to perform things the way the device (firmware) expects them and not freely.
So, even if you had access to the internal definition of the device, you would still struggle to overcome the firmware limitations and expectations.
In other words, if you want to be safe, try to achieve the best you can via remapping. The communication part with the device is already taken care by VirtualDJ and it's internal definition and it's compliant with the device firmware.
geposted Tue 28 Sep 21 @ 6:33 pm