A rock solid scratch encoder.

[Fatlimey]

A quick note on creating a rock solid rotary encoder for scratch purposes.
The trick with quadrature rotary encoders is that it has two lines that alternate high/low half a turn out of sync with each other.



By inspecting these two pins every time they change from high-to-low or low-to-high you can work out which direction the encoder has rotated. Simple enough.

Two problems, if you don't check the encoders often enough you'll miss transitions and get confused about the direction that it moved. This is especially true when scratch DJs are doing those tiny, high speed scribbling movements they love so much. Usually when you absolutely must know when an event has happened, we connect the event up to the "interrupt" pin of the microcontroller - this is a special pin that when it changes state causes a specific piece of code to be excecuted, called an "interrupt service routine". Great, but some controllers only accept interrupts on the rising edge of a signal, and for a quadrature encoder we need to catch the rising AND the falling edges.

So the trick is to have a dedicated chip listening to the movements and recording, for a short amount of time, how much movement there was. We do this using a pair of chips - first, a LS7804 "quadrature decoder" converts the two pins to a +1/-1 signal, which we feed into a "up down binary counter", which keeps track of how many events have happened since we last checked, and in which direction they happened.

http://www.lsicsi.com/pdfs/Data_Shee...083_LS7084.pdf
http://www.fairchildsemi.com/ds/74%2F74F579.pdf

Figure 6a here: http://doc.chipfind.ru/html/lsi/ls7084.html

Maybe the 8-bit counter is overkill, if we sample often enough a 4-bit counter would do fine. Combine these two chips and you get rock solid scratching, never missing a motion.

[pilmat]

Sooo, what your saying is that if I hack the jogs out of my VCI-100 (which are 8-bit, I believe) and build a little control circuit with the chips you linked, I could input this into say a MidiFighter (and program the control in) and have high resolution jogs? Or am I whacked? (whacked = mechanical eng working with circuits...)

I love it when people think out loud!

Phil.

[Fatlimey]

Erm, there's resolution in terms of "detecting the smallest movement humanly possible" and there's resolution "reacting to a movement in a fraction of a second". One is "angular resolution" and one is "latency" (the amount of time between a movement and the computer reacting to it).

I understand that having more than 127 values on a pitch slider is highly desirable, but having a scratch control that sends out two bytes of highres MIDI data every movement instead of just one byte that represents the size of a movement since the last time sample (a number less than +/-64 'ticks' of angle change) is just shooting itself in the foot.

This hack would give you reliable angular resolution but do nothing for the latency. Which are you wishing for?

[haze324]

this thread sounds interesting --- but WAY over my head.

I do better with pictures

[Fatlimey]

Added some pictures.

[pilmat]

Then what is the solution for platter tactile optimization? Devices like the Otus and Vestax One offer midi control in the range of tactile sensitivity required, what is their secret and how can we exploit that into a reasonable ($-wise) control? Or is the problem software based in Traktor?

If so, would it be possible to output a code stream from control circuit at 2 kHz (DVS style with the apropriate position code attached) and use a platter to manipulate that stream?

More out load thinking...

[sgb]

Maybe the 8-bit counter is overkill, if we sample often enough a 4-bit counter would do fine. Combine these two chips and you get rock solid scratching, never missing a motion.

Fatlimey,
The largest problem is not if you are going to be able to sample enough data. Rather, its ensuring that you can detect the precise enough movements with an encoder that has sufficient resolution in a single rotation. If the encoder has 7 bits of resolutions, it will only be able to detect movements in 128 locations in a single rotation, ensuring that you will not be able to detect small, precise movements. That is why if you open up the VCI-100 or VCI-300, the encoder consists of a small disc with thousands of holes. I believe the VCI has 4096, but that is an educated guess.

Take at look at the document I put together about lubricating the VCI jogwheel, I believe there is a picture of the encoder in there.

Further, from what I understand, the VCI-300 and NS-7 MIDI output (some people say HID, but I never saw any HID data) are different from standard 7-bit MIDI encoder messages from encoders used in jog wheels. From what I recall, the VCI-100 7-bit MIDI encoder messages actually represent VELOCITY of the jog wheel. However, VCI-300 and NS-7 send POSITION information along with a timestamp, allowing computation of velocity, acceleration, and jerk (this is likely why Traktor Pro does not support the NS7/VCI-300/V7 just yet).

[pilmat]

sgb, what would jerk be needed for? Acceleration on reversal?

Phil.

[sgb]

sgb, what would jerk be needed for? Acceleration on reversal?

Phil.

Jerk is just the derivative of acceleration (Position = distance, Velocity = distance/time, Acceleration = distance/time^2, Jerk = distance/time^3). I'm not sure if it would be used, I'm just hypothesizing you could obtain that data. It probably does affect the sound of a scratch to a certain extent, but to what extent is debatable.

[Mudo]

...

But then we need some code for take these interrupts and manage them or we are talking only as a mod?

...