I am looking for some help with a very sensitive quadratic encoder wheel.

leejsmith

Member
For the last year I have been working on a project to convert faulty pioneer cdj 800 and 1000 to midi devices using teensy 3.2 and 3.6.

https://www.youtube.com/watch?v=bT6gpcupwyQ&list=PLm24lW1EHXRBq56NebYlt-0IqBr6Gwxkd

I made a full series of videos showing how to wire mod a faulty unit and now designed replacement PCB that can be swapped over. I am working my way through testing and optimising each part and I am struggling with reading the encoder on the jog wheel. It works, but it's just too fast and I have to reduce the sensitivity in Traktor down to 15%. This still has some problems when I move the jog wheel very fast, but I think that is down to traktor and the reduced sensitivity setting.

I looked at the encoder.h and have tried changing the case select so it only responds to 2 states and not the 4 from the original and this helped a lot, but it's still way to fast. How can I reduce the number of midi commands I send from moving the jog wheel without missing the steps from the encoder wheel.

Code:
switch (state) {
			case 1: //case 7: case 8: case 14:
				arg->position++;
				return;
			case 2: //case 4: case 11: case 13:
				arg->position--;
				return;
			case 3: case 12:
				arg->position += 2;
				return;
			case 6: case 9:
				arg->position -= 2;
				return;
		}
 
I am trying some simple code that counts up to a set number before sending the midi command and it seams to work. I can adjust the setting on the tft screen and I have found waiting for 8 movements from the encoder before I send the midi and then 50% sensitive in Traktor gives me the feeling I want to replicate using CD on the original CDJ 1000.
 
Wow, nice work on the video! :)

Yeah, if the encoder has a lot more resolution, the solution is usually to divide the results by some constant.
 
I really would like to replace the simple quad encoder from the original cdj with something I can track the actual position, but if I want to make kits to sell at some point it would add to much to what I need to produce. The teensy can keep up with the signals no trouble, it just sends way to much data to the dj software so with some different gearing I could also solve this problem.
 
You can limit by time rather than magnitude.

An elapsed time since previous sent message can be checked and a new message sent only if some minimum threshold time has elapsed.
 
You can limit by time rather than magnitude.

An elapsed time since previous sent message can be checked and a new message sent only if some minimum threshold time has elapsed.

I guess that depends on what you are actually sending... I guess you are generating timing codes then not so much...


In my defence you didn't really spell out what you are doing.
 
Back
Top