Midifighter Twister - Firmware - No update since August 2014 - Page 2
Page 2 of 8 FirstFirst 123456 ... LastLast
Results 11 to 20 of 80
  1. #11
    Newbie
    Join Date
    May 2016
    Posts
    2

    Default

    Quote Originally Posted by EanGolden View Post
    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.

    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.
    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.

  2. #12
    Newbie
    Join Date
    May 2016
    Posts
    3

    Default Major Bug

    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!

  3. #13
    DJTT Administrator del Ritmo padi_04's Avatar
    Join Date
    Nov 2009
    Location
    Argentina
    Posts
    6,493

    Default

    Quote Originally Posted by KlangManipulation View Post
    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!
    That is one of the bugs getting fixed with this update

  4. #14
    Newbie
    Join Date
    May 2016
    Posts
    1

    Default

    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?

    Regards,

    Quote Originally Posted by padi_04 View Post
    That is one of the bugs getting fixed with this update

  5. #15
    Newbie
    Join Date
    Dec 2014
    Posts
    2

    Default Any update?

    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.

  6. #16
    Tech Guru DJDoubleYou's Avatar
    Join Date
    Mar 2011
    Location
    Hyperspace
    Posts
    1,176

    Default

    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.
    DN-X1600 | 2x X1 MKI | APC 20 | MC-505 | MF Pro & Spectra | Kontrol S4 MKI | XBoard 49

  7. #17
    Mr. Golden EanGolden's Avatar
    Join Date
    Mar 2008
    Location
    San Francisco
    Posts
    970

    Default

    Hey Everyone, it's been 30 days and I have an update for you.

    1. 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.

    2. 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.
    Last edited by EanGolden; 05-16-2016 at 12:03 PM.

  8. #18
    Mr. Golden EanGolden's Avatar
    Join Date
    Mar 2008
    Location
    San Francisco
    Posts
    970

    Red face Quick Firmware update for you!

    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.

    Sincerely,

    Ean Golden

  9. #19
    Tech Guru DJDoubleYou's Avatar
    Join Date
    Mar 2011
    Location
    Hyperspace
    Posts
    1,176

    Default

    Awesome reaction and super cool how you are still personally involved in these things!
    DN-X1600 | 2x X1 MKI | APC 20 | MC-505 | MF Pro & Spectra | Kontrol S4 MKI | XBoard 49

  10. #20
    Newbie
    Join Date
    Apr 2016
    Posts
    3

    Default

    Quote Originally Posted by EanGolden View Post
    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.
    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.

Page 2 of 8 FirstFirst 123456 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •