The LED rings do not respond to midi while the value is controlled by the knob.
I’m Trying to map the twister so that a single knob controls multiple values based on modifiers, I therefore need the LED indicators to always respond to the midi signals.
I have the knobs set to encoder mode and mapped as relative in traktor, it all works except the LED feedback.
If I map an encoder 1 to control an eq knob and the leds to indicate the position, the LEDS will not change unless something else is controlling the software parameter (i.e. Mouse or a different encoder).
I presume this is a firmware bug, but it completes ruins my planned mapping, leaving the twister useless as I have no idea where my controls are pointing.
What you have experiencing is not a bug. While any of the Twister’s Encoders is in the 3Fh mode you won’t be getting any feedback from the LED rings.
Though, I’m curious to see your mapping and then I’d hopefully be able to help you out with setting your knobs in the CC Encoder mode where the LED feedback is mappable.
I can get LED feedback by outputting messages from traktor and it sort of works, it just won’t update if for example CC01 is controlling gain and gain position is set to out on CC01.
However if the out is set to any other CC it works fine but the output has to be for an LED ring around a different encoder to the one controlling the parameter. The values update correctly if send monitor state is used, however it is a pain turning an encoder and then pushing a button to see the control value.
The reason I want to map as encoders with feedback controlled by traktor is so that I can use modifiers to control functions, the mapping I’m working on will give up to 15 layers per twister bank, where each strip of 4 encoders can be on any layer.
I’ll happily upload the unfinished mapping if you would like to see it.
I’ve attached my twister configuration and traktor mappings.
I’ve added a mapping called problem demo that shows whats happening. Encoders 2 & 6 (If 1 is top right) both control deck A gain and the LED rings are both mapped to show the position of trakors gain knob. Also if either is pushed they both show pre fader VU (which is a function I’d like in my mapping).
Try turning each of these and see what happens, also try changing the parameter using the mouse or other controller.
I’ve also attached a plan for the mapping which is part done, should help you understand what i’m trying to do.
Left Side Button 1 swaps to bank 3. Encoder 1 on bank 3 changes layers (for the left hand column), pushing this encoder swaps to bank 1 where the controls are similar to the plan.
Thanks for the files mate. Alright, Ive been able to reproduce the problem on my Twister now - it seems that 3Fh encoder mode has indeed exposed the LED Ring feedback even though the Encoders are not set as a CC.
Ok, this is now on the bug radar and we will take care of that one! No worries
In the mid time, you can go ahead and change the Encoder mode in to CC which actually is designed for mapping this same controls in absolute mode.
Yes, the encoders seem to interfere/block incoming midi. There just needs to be a separation when in encoder mode so that the only thing controlling the LEDs is incoming MIDI and not the encoders themselves.
I have a basic mapping working for a 2 deck mixer, but it’s extremely limited compared to my planned mapping.
If I use CC mode I can’t properly control the LED feedback, for example sending the pre fader VU signal operates the LEDs but also updates the CC position so the position of the twisters virtual knob constantly changes causing unpredictable jumps in gain when turned.
Mapping as 3FH encoders and using traktor (or scripts for other programs) to control the feedback opens up so many possibilities compared to the CC mode.
I hope someone sorts this bug soon as the twister is very nearly one of the most powerful controllers there is.
We are working on new update. This is getting fix in the next couple of months so please be patient. Personally I found good use of that exposed ring behavior - sometimes it’s cool to have a move loop knob in 3Fh mode and than also display track position on the same knob (or maybe a VU or beat phase meter). I can always send a note with zero velocity in the mapping to disengage LED rings when I don’t need them or have them showing in full velocity as well.
+1 This is an issue when controlling Live with nativeKONTROL DDC as well. The solution here is to switch banks and back… The LED ring shows the current state of the bank but doesn’t update when changed.
The same problem affects encoders in CC mode. Actually, I just noticed rob2192 discovered this last year!
I was attempting to work around the 3Fh encoder mode by resetting the CC value to one when it reaches 127 and to 126 when it reaches zero. As part of a Pure Data patch this would allow an arbitrary resolution (e.g. 1-500 or whatever) of knob twisting. The LED ring would be controlled continuously by MIDI IN CCs which is possible but only while the associated knob is NOT twisting.
This would reproduce the 3Fh encoder mode behaviour (but with a greater resolution as far as I can tell i.e., more increments per turn) and open up this controller to all sorts of new applications via Pure Data . . . .
. . . but not until this old bug is fixed . . . .
I appreciate any work already done towards this fix but these units ain’t cheap!
Just plugged my twister in to check for an update, the latest firmware is 13th august 2014.
So i’m guessing this isn’t fixed.
If DJTT team aren’t working on bug fixes and updates it would be nice if they made the firmware open source so someone else could.
It’s such a universal control device it could go beyond DJ and music production use - i’m sure I could design some games for the raspberry pi utilise it.
I agree, it’s a shame. It could be such a perfect universal programmer for VST’s. I actually sold mine and got a Livid Code instead to use with nativeKONTROL DDC. But if this gets fixed I might buy two just for the brilliant form factor and RGB that the Code doesn’t have…
I also have reported this bug repeatedly for around 18 months now. DJTechTools support has told me dozens of times over that period that an update is only a few weeks/months away. Their responses have ranged from grateful to dismissive. Last I heard, they don’t have a programmer for the twister firmware and would like to hire one. Such a hire does not seem an actionable priority, however, as it’s been over 9 months. In fact, I now treat the Twister controller and firmware as a tacitly unsupported product. That’s pretty unprofessional on their part and, when combined with their words of assurance and justifications, incredulous.
Take Stewe’s response above (which I find typical of the DJTechTools support interactions I have had regarding this twister bug): first, not a bug, this is expected behaviour; next, it is a bug, we’re on it; almost a year goes by; we’re really on it, please be patient; almost a year goes by; no progress, no response; and let’s not forget the justifying of an unreported removal of a feature supported in earlier firmware as some kind of useful feature of the new firmware, when it has taken away usability from and clearly constitutes a “dealbreaker” to the OP and the others who have added their voices to this thread. My experience has also included other support personnel telling me that the problem is my mapping, that this bug has already been fixed, that this bug is not important and doesn’t effect anyone but myself, that I can accomplish the same mapping with CC input (despite giving use cases to the contrary), and that this LED feedback is not a specification of the hardware as advertised. These responses and behaviour are, unfortunately, all to common in the tech world. I guess I expected more.
I really want the Twister to be great; it has so much potential. I want to buy more DJTechTools products and recommend them to my peers, but instead I have to express my ambivalence and disappointment with the Twister and the company’s development resources and product support. I also have to share my decision to not make another purchase from DJTechTools until this issue has been resolved. I wanted to buy a MidiFighter 3D over a year and a half ago. I’m still waiting.
In setting up my new Twister for performance, I think I’ve run into the same problem. It is a bit of a dealbreaker for the device for me, as it basically breaks software-side LED control for ENC 3FH mode. And beyond that, turning a knob in CC mode seems to override the LED ring values being set via MIDI input as well, resulting in discontinuous value jumps when the value is controlled by software - I think this explains a previous users issue w/r/t LED ring changes when a knob is pressed (probably, pressing the knob with a small amount of twist is causing the LED ring MIDI input to be ignored). The CC and ENC issues seem like the same bug (MIDI input is ignored when turning knob), though they might be different things.
I would be happy to fix this in the firmware (if it’s at all similar to the old open-sourced MIDI fighter fw, the fix shouldn’t be difficult), but as far as i can tell the twister FW was never made public?
I’d be sad to have to return my Twister - it seems like a huge improvement over the build quality problems I’ve had with the Livid Code, and there are basically no other options available on the market. I was excited to get this working…
Plenty of people around here who can program and could do some incredible things with the hardware, I push for open source but failing that they should be able to get someone to fix the bugs.
Opening up the firmware would allow so many possibilities far beyond drum sequencing, it would surely make it appeal to more users and therefore boost sales.
Actually it’s pretty annoying…
. . . . I hope progress on the fix is going well. 