Page 1 of 14 1234511 ... LastLast
Results 1 to 10 of 133
  1. #1
    Tech Convert
    Join Date
    Aug 2010
    Posts
    13

    Default VCI-100 unofficial firmware 1.3.1 available

    UPDATE: Version 1.3.3 released, later in this thread!

    == Intro ==

    Hi everybody,

    I recently purchased a VCI-100 SE. After reading a lot of different reviews about different USB DJ controller it seemed like the right choice. With all those good feedbacks and reviews I read, I was very surprised to receive a device with which you can't do serious beat matching. It's only after searching this forum that I found all the complaints about this particular problem and the workarounds.

    But there's one really good thing about the VCI-100 it's the fact that you can reprogram it. I'm quite into hardware hacking in general, so I downloaded the 1.3 firmware, fired up my favorite disassembler, and wasted some time on it in order to fix it

    I'm very happy to present an unofficial 1.3.1 version of the firmware that has a 4x better precision for pitch faders than previous firmwares, look at the attached picture to see what that means!

    == New features ==

    • Improved pitch faders resolution (512 steps instead of 128)

    == Howto ==

    To upgrade your firmware you need to follow the 1.3 upgrade instructions, but with the proper firmware file.

    This new firmware sends the old messages as well as the new ones, so it's compatible with the DJtechtools Traktor settings out of the box, but if you want the extra bits of precision you need to remap your Tempo settings (someone please make an import file for Traktor?)

    - Deck A/C Tempo = CH02.PitchBend
    - Deck B/D Tempo = CH03.PitchBend
    - Deck A/C Tempo Reset = CH02.Note.C0
    - Deck B/D Tempo Reset = CH02.Note.C#0

    == Technical Details ==

    All the analog faders & knobs on the VCI-100 are read using the main MCU (h8/300) built-in AD converters. Those converters have a precision of 10 bits. The previous firmwares converted those signals to 7 bits so it can fit in a regular Control Change MIDI message. In my 1.3.1 firmware, the pitch faders are converted to 9 bits then sent as a Pitch Bend MIDI message which has a 14 bits precision.

    Why using 9 bits instead of 10 bits ? I worry that if the analog value is just between two digital values, it may oscillate between the two (due to noise) and so MIDI messages may be sent even when the pitch fader didn't move. The extra bit is required to avoid this kind of situation.

    In theory it's possible to use 14 bits of precision for the pitch faders using a small hardware mod involving an external AD. Is it worth it? I dont know!

    For interested people I've attached a couple of screenshots from the reverse-engineering process showing the same piece of code before and after all the guesswork and analysis

    == Closing words ==

    While I tested it, this release is a beta version so I'm waiting for your feedback. I've taken great care of polishing all the details, and you don't risk anything as you can always downgrade to 1.3 or 1.2 afterwards.

    Have fun!

    DaveX
    Attached Images Attached Images
    Attached Files Attached Files
    Last edited by DaveX; 08-18-2010 at 12:15 PM. Reason: Added screenshots and some structure to the post

  2. #2
    DJTT Infectious Moderator photojojo's Avatar
    Join Date
    Apr 2010
    Location
    Sherman, TX
    Posts
    14,086

    Default

    Curious to see if anyone tries this firmware.

  3. #3
    Tech Wizard
    Join Date
    Mar 2009
    Posts
    47

    Default

    Quote Originally Posted by photojojo View Post
    Curious to see if anyone tries this firmware.
    you go first

    ill have to check back later and decide if i want to dig out my usb-serial cable

  4. #4
    Tech Mentor Sasha Solo's Avatar
    Join Date
    Nov 2008
    Location
    Brooklyn, NY
    Posts
    131

    Default

    I might check this out! Would be nice if any of the admins check this out and let us know if its safe!

    SS
    2x Technics M5G :: Traktor 3.4/PRO2 :: Vestax VCI-100
    M-Audio Ultra :: Macbook Pro 13" 2010

  5. #5
    Tech Convert
    Join Date
    Aug 2010
    Posts
    13

    Default

    I updated the post with small details, you don't risk anything upgrading as you can always downgrade to 1.2 or 1.3. But I also hope one of the admins checks it out!

  6. #6
    Tech Guru MaxOne's Avatar
    Join Date
    Jan 2009
    Location
    London, UK
    Posts
    2,814

    Default

    I haven't got my firmware upgrade kit yet but this looks interesting i must say...
    Macbook Pro 15" OS X 10.7.5, TSP 2.6.1, Technics 1200 mkii, X1 mk2, X1, DJM 900, KRK VXT4s, CLICK FOR PICS
    ----------------------------

  7. #7
    DJTT Super Moderator midifidler's Avatar
    Join Date
    Mar 2008
    Location
    San Francisco
    Posts
    1,934

    Default

    I'm forwarding this to Ean now - I'm sure he will be in contact shortly.

    Very nice work!

  8. #8
    Tech Guru
    Join Date
    Oct 2008
    Location
    West Coast, United States
    Posts
    632

    Default

    Holy God, DaveX - can you do this with the jog wheels as well?
    MacBook 2.4GHz, 6GB, Traktor Pro, Ableton Live, Bomes MT, Audio Kontrol 1, Vestax VCI-100 SE Custom, M-Audio Axiom 25, Akai APC40, NI Maschine, 2x Midi Fighters (c/o DJ TechTools - Thanks!!)

    Mixcloud DJ Sets

  9. #9
    Tech Mentor
    Join Date
    Nov 2009
    Posts
    389

    Default

    nice work dave.thanx for sharing.i've never flashed but will give it a try when i get back thursday

  10. #10
    DJTT Super Moderator Fatlimey's Avatar
    Join Date
    Mar 2008
    Location
    Redmond, WA
    Posts
    1,178

    Default

    DaveX, blinkin' marvellous work. *applause*

    Some improvements you might like to make. Truncating an ADC value to remove LSB noise doesn't unfortunately work for all values in the number line, only most of them. Take for instance the 10-bit value:

    010011111?

    where "?" is the noisy bit. The ADC value is wobbling between two digital values:

    0100111111 and 0101000000

    Truncating to 7 bits will still send a noisy value to the result because the chain of 1-bits causes the noise to "rise up" through the value and appear in the truncated end result.

    The trick to "debouncing" ADC reads is to keep a copy of the previous ADC value at full resolution and only pass on the new ADC value to the truncation code if the full-res value has changed by, say, plus or minus two bits. This adds a bit of hysteresis into the system that will remove noise but still allow actual movement to be recorded quickly. Here's some code:

    Code:
            // Make sure any change in the value is due to
            // user action and not sampling noise. We do this by making sure the
            // value has changed by a minimum amount before we say it has
            // changed - essentially adding a small amount of Hysteresis into
            // the system. This part happens at full resolution.
            for (uint8_t i=0; i<4; ++i) {
                // Read the ADC value once and record it for use everywhere else.
                int16_t value = adc_read(i);
                // NOTE: Need a signed 16-bit value for the difference
                int16_t difference = value - g_analog_prev[i];
                // If the difference is less than three bits either way we
                // assume the difference was noise and the ADC was not changed.
                if (abs(difference) < 8) {
                    // do not send the noisy new value, use the old reliable one.
                    adc_value[i] = g_analog_prev[i];
                } else {
                    adc_value[i] = value;
                }
            }
    
            // Next, loop over these fresh ADC values to see if, after
            // truncation, they have changed and a MIDI event needs
            // to be generated.
            for (uint8_t i=0; i<4; ++i) {
    
                // Lose the bottom three bits of each 10-bit ADC value,
                // converting it to a 7-bit CC value.
                uint8_t value = (uint8_t)(adc_value[i] >> 3);
                uint8_t prev_value = (uint8_t)(g_analog_prev[i] >> 3);
    
                // Compare the CC value to the previous one sent. If there has
                // been a change, generate a new MIDI Control Change event
                // sending the new value.
                if (value != prev_value) {
                    // Generate the default CC event.
                    midi_stream_cc(16 + i, value);
                    ....
    
                    // Record the new ADC value, at full resolution, for the next
                    // time through.
                    g_analog_prev[i] = adc_value[i];
               }
               ....
            }
    Do this and your faders return rock solid results. This code comes from a Midifighter update I'm working on.

    Looks like you'll have to find a few unused words of RAM to use for the previous values. Also, if you have any clue why the lights flicker when the unit recieves MIDI input I'd love to try and fix that. My guess is there's no latch on the LED values and the flickering is the LED bits rippling through the serial input. No good way to fix that unfortunately.

    Keep up the good work! Should you feel the desire to share your discoveries as an open source Creative Commons project, I'd love to help you out. Check your PM!

Page 1 of 14 1234511 ... 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
  •