Midifighter Twister - Firmware - No update since August 2014
Hey Stewe and Dj Tech Tools staff.
Back on 03-04-2016, 08:45 AM, we were told (Stewe) that “…working on it…will keep you posted…”. Because you told us to wait for a cure, we did. This hasn’t happened, we still are waiting on an update for over a year.
Crying that “we are a small team” whilst promising us “something is coming” only makes your paying customers sit in blind hope whilst something may never come. If you cannot meet the demands of your community, just be honest with us and say so. Please stop making bullshit promises that you cannot live up to and telling us you can fix it if you can’t. We just need to know honestly if it will ever be fixed or now. We can deal with it if you cant, we just want to know if it’s realistically possible. We are paying customers, but beyond that we are capable of being told that there is no fix coming and can circumvent inevitabilities.
There are some serious and well established defects with the current firmware (eg midi sync issues), nobody is expecting these are easy to fix. But please be honest with us and stop sticking the “a fix is coming” thumb up our asses. You could pay us a little more respect by saying something like “it’s too hard for us to find a fix right now” or “our business needs to focus on other areas” or whatever other understandable reason is making it too hard to fix - we know that these things are sometimes hard to fix.
Please stop feeding us bullshit and lies, when we are the community that built you up and purchased your products.
Or just make the Midi Fighter Twister firmware open source!
This is the third thread about the Twister firmware bugs and still no offical date when the firmware update will come - and some bugs are easy to fix,so they can start with those.
Best advice for everyone: Don’t buy any Midifighter Twister before a new firmware is released!
I felt it was important to address this directly, and honestly. You are absolutely right, updates to the Twister have taken too long and we need to fix that - quickly! I’m personally going to make it a priority to address this and make sure everyone feels heard, and their problems fixed.
A small background on why this has taken so long
Last year, in order to save money and not go under - we had to let go of our full time engineers. This meant that all software development ended while we looked for freelance engineers to continue the product updates.
The bottom line is that we just need to hire a good engineer to work on the code base or find other creative ways to get the bugs fixed.
Psyko - Your suggestion is great, and I agree - but would anyone actually use and update an open source firmware? The original MF code was open source but almost no-one worked on the code.
To everyone else - any introductions or ideas for good firmware engineers who can help us continue MF twister development would be really appreciated
Practically speaking, here is a timeline you can count on:
We will find someone and get the bugs updated in the next 30 days. That feels like a reasonable deadline, and something which we can make happen. If anyone wants to add things to this thread that are most important to you, that would be very appreciated.
As always, thank you for the support and patience. Dj TechTools grew out of my passion to help other djs and it’s made possible by the contributions of everyone from this community.
Thanks Ean, for both jumping into this but for finally sharing some transparency on the issue, your honesty is really appreciated.
It’s interesting to know that you tried going open source but nobody jumped on it, I guess being such a niche product most users are probably happier making music than writing code. Being a software engineer myself I’m way keen to help where I can and have some questions for you;
Where did you try hosting the code and how did you promote it’s awareness within coding communities?
What language is the code and how clean/messy would you say it currently is?
What are your thoughts about crowdsourcing the work, eg bountify.co, guru.com, etc?
As for what is most important, I only have 2 things;
Fix the bug whereby the pulsing/flashing animation does not sync to incoming MIDI.
Most settings can be changed via MIDI CC but some settings can only be changed via the Midifigher Utility. It would be great to be able to set an encoder’s detent settings, sensitivity and indicator type via MIDI CC (or document how to do it by sending SYSEX without the device having to do a restart).
thanks for the informative reply - new firmware in 30 days sounds great!
As I have some programming skills as well (but beeing no professional) I would be interested in writing my own firmware (for my special needs - using the Twister as a Davinci Resolve controller). And I can think of many other applications where the well designed Twister would be a perfect fit, but need special firmware. (C code and a tool to upload the firmware would be perfect - something like the Arduino IDE).
Most importen bugs (to me):
The LEDs can’t be controlled by incoming MIDI as long as the encoder is used. The Twister ignores all incoming LED controll MIDI messages for about 0.2 seconds after any event related to the encoder, even in Enc 3FH/41H mode.
(see noofny) Certain settings like detent, sensitivity, indicator type,… can’t be controlled by MIDI CC (and need a restart of the Twister).
Thank you for the detailed information - particularly around what we can improve. It’s clear what needs to be done and we can probably knock out the main things pretty quickly.
To answer your questions:
What state is the code in? It appears to be well commented and organized
What language is it written in? C/C++
@noofny - feel free to reach out to me directly ean (At) dj techtools.com and perhaps we can find a way to get you involved with the fixes!
Finally, thank you both (and to everyone else) for vocally and directly voicing these issues and bringing them to my attention. With your help, we can hopefully make the midi fighters even better products.
Now, what I can do is probably going to be quite limited (I don’t own a Twister, I have a lot less time on my hands now, and I haven’t done any firmware development in a few years (and will have to see if I can find my atmel development tools…)), but I would be happy to help regardless. I’m not sure if the Twister codebase is based on the MF/MF Pro/MF3D code – if its not, I probably won’t be able to help much – but if it is, I can at least help somebody else familiarise themselves with the code, explain how the SysEx stuff works etc (although I imagine I’ll need to familiarise myself with the code, since I’m sure its evolved since I last saw it).
Ean: I’d be willing to sign an NDA if you wish to keep the code closed source.
I’d also be happy to actually fix bugs or make other smallish changes (if its even possible without a Twister), but as I said, my time is limited so I wouldn’t be able to commit to any specific timelines or anything
Still, let me know if there’s something I can do to help.
When the encoder is in 3FH/41H mode and you turn it slowly the MF Twister sometimes (randomly) sends both step right (65) and step left (63) CC signals at the same time, instead of only the one signal corresponding to the direction.
Some programms ignore parts of those contradicting messages, which when turning the encoder backwards with higher speed results in random offsets from the start position.
I’m not sure if its a software problem (the Twister sending those wrong values due to a bug) or if its a hardware problem (the pulsencoder sitting exactly between two values unable to decide which is correct).
I am pretty sure if you just put your source code on GitHub.com, there would be at least one person who’d happily help you to at least fix the bugs. It really takes just a single person…
Hello guys!
Maybe this is the right place to write it. A few months ago I wrote a message to support but it was totally ignored with no answer.
My complaints are about just the basic functionality - the sync between Midi Fighter Utility and my Twister.
The bug which makes me mad angry is that sometimes when I set a new colours setup or change anything in MFU and send it to the MF, it COMPLETELY messes up my midi numbers which I want to stay as they are (1-64 stepwise). Then it of course completely messes my midi mappings in Ableton, because eg. the knob sending cc23 before is now sending some random different number (mostly they change to 64). Then I have to check all the midi numbers and set them manually again and again. I have done it for many times always with a big frustration.
Beside that there are some other bugs, such as sometimes one colour randomly changes with no reason or MFU crashes, or does not load the current state of the device correctly.
I would also very appreciate selecting multiple knobs with SHIFT rather than having to click every knob manually and de-click it afterwards and I agree with guys above about being available to control more funtions via midi from Ableton rather than via buggy MFU.
To be honest I use MF Twister with USB hub when on stage which isn’t recommended, BUT I never make changes in setup and any syncing through USB hub, I always stick it directly to my macbook when connecting to MidiFighter Utility. (When performing, I have simply no way to avoid usb hub, since my macbook pro has only 2 slots and my whole live gear contains 6 usb devices, isn’t it a quite usual situation for all live performers? I have bought dLink powered hub - DUB H7 recommended here on DJTT in the related article)
Anyone can help how to solve this problems? I’d be really very happy if the new firmware solved these essential bugs.
My setup:
Macbook pro 2011
Ableton 9.6. legit
Focusrite saffire pro 40
I bought a Twister in early 2015 and immediately ran into some of the bugs that other people have been complaining about. I am a software developer and don’t do anything related to DJing. I bought the Twister to have a control device for my own software and to use it with PureData. Because of bugs I barely use it and have bought several other MIDI controllers in search of something that will do what I want. I would buy an MF3D as well but I am worried it will have problems like the Twister.
Lately I am looking into building my own devices as I have some experience with electronics. I may rip out the Twister internals and replace them with a Teensy/Arduino board. I would rather save time and use ready-made devices but I need to be able to program the firmware in order to get them to do what I want. I did spend some time reverse-engingeering all of the SysEx messages that the MIDI Fighter Utility uses to configure the Twister. I can now configure all aspects of the encoders from my own programs which I find much more useful than the MFU tool. But I still have problems with various bugs.
The whole reason I bought from DJTechTools was the history of tutorial videos (some even on how to make custom MIDI devices) and of selling do-it-yourself kits and providing firmware source code. I think open-sourcing the Twister and 3D firmware would be enormously beneficial to everyone. There are several software developers in the forums that have asked for this. I would be happy if you just open-sourced parts of it. For instance I do not use the Twister sequencer at all so I don’t care if source to that is available. Information on how to upload custom firmware and how to read the encoders and set the LEDs would be great. If that is not possible I would, like others have offered, sign an NDA and try to fix problems for free.
Hi, i found a bug that is very important to fix.
Shift encoder toggle isnt working if knob is set to “enc 3FH/41H”!
if CC mode is selected it works fine.
i hope som ething will happen soon…
best regards!
I don’t know if this is a known issue or I am doing something wrong. I just got my Twister yesterday and was programming one of the knobs to be 3fh/41h with the Encoder Hold function. I set midi channel 1 for normal encoder function and midi channel 2 for hold encoder function. It seems like moving the encoder when pushed doesn’t make any difference. It still sends the data through midi channel 1 so making it impossible to control two different knobs in my DAW. When I set the encoder to CC, channel 2 and 1 work fine and independently. Why doesn’t the twister send 3fh/41h data through midi channel 2 when pushed as I configured it?
Hi is there any update to the progress of the new firmware, we were told there would be something in the next 30 days, but that time is up and I’ve seen no info yet.
Hey Ean & Padi_04,
I’ve personally tinkered with the MF pro and classic firmware you published and think opensource is the way to go for the rest of your devices too. I get that development takes a lot of time and opensource is not always the preferred solution but I think there are a lot of C coders (including me) that would not mind debugging the code, DJTT is a wonderful company that has the best customer service i have ever experienced and is maintained for DJ’s and by DJ’s. I think many people would be happy to contribute.
Hey Everyone, it’s been 30 days and I have an update for you.
Many of the most important bugs have been fixed (but not all) and an update should be rolled out this week. I will post later today with more details on what we got done.
I am very interested in open sourcing the firmware so everyone in this thread can take the code in any direction they want and share that work with others.
My question for #2 is: Aside from putting that on GitHub, how does the management work? Do people just fork the code and use the bits they want? I assume we end up with a lot of various builds, and not one single code base.
Thanks again for everyone’s feedback and input - it’s been very helpful
There is a alpha firmware update attatched here that has the following fixes
LED Midi Response speed has been improved and the LEDS now react quickly to Ableton output when turning encoders. This should be performance tested to ensure it does not cause problems.
Button Toggle Sync with Ableton. The buttons now sync up with Ableton when in button toggle mode.
Shift Encoder Toggle Now Works This feature now works for CC’s and ENC values.
Lighting CC always Matches the Control CC Changing a encoders CC value now also changes the lighting input to match.
The following will be fixed this week
Dedicated Shift Encoder/CC Channel Holding and turning knobs will now send the same value but on Midi Channel 5, to make mapping of the 2nd function easy and clean.
Animations Match Midi Clock Blinking animations will sync up to the output of Ableton’s midi clock.
Independent control of the LED rings and RGB LED You will be able to address each of them independently on their own channel.
*Encoders ignore incoming midi when turned We are going to speed this up and make some changes that will minimize this problem dramatically.
We will also fix the following user’s concerns
@Psyko - We will fix the bug where two messages are randomly sent at the same time. @Kapush - This needs to be tested further, but no one else seems to have this problem. You may want to try a factory reset. @Slayde - We will open source the firmware once this build is done. @KlangManipulation - That has been fixed. @syntexis - This will be addressed by moving it to a new channel in the fix this week @Noofny - For SYSEX updating of device settings, we will open source the firmware so you can go to town
Finally - after this update is complete we will open a new thread and give everyone interested access to the firmware.
Hello, and thank you for this. A few of my observations:
In the beginning, just put everything on GitHub and provide the basic documentation. Your source is meant for technically minded users, so they just need the basic info: How to compile, how to upload it to the device and what to do if the hardware gets bricked during the process. Don’t forget to provide all necessary details of your hardware (processor, memory etc). Provide warnings about what is dangerous and could permanently damage the hardware. Clearly state at the beginning of the README.md that “This is the ONLY source of the latest OFFICIAL firmware”. Put a warning there that this is not meant for end users and provide a brief info (link) for the end users about how to download / update the compiled official firmware. At this stage, you don’t have to bother with detailed documentation (but it helps if you can provide it, of course). If you want to make the life extra easy for the developers, you could provide simplest virtual Linux image (e.g. for VirtualBox) pre-configured to allow immediate building.
Next, hopefully, some ingenious person or persons will fork the whole codebase and start doing wonderful stuff with it. You should provide a forum for these wonderful people where they will discuss stuff that’s completely arcane for your end users. Note that at this first stage, you don’t have to do anything else, except maybe clarify the important answers that aren’t entirely clear from your GitHub repo. You should very clearly separate the bugreports of your end users from the discussions of firmware developers - these two groups of people should rarely intersect because they speak different languages.
Only after someone provides something worthy, you should (carefully) consider accepting it back into your repo and/or hiring that person.
, DJTT made it much prettier later) version of the utility.
