Jogwheel construction
Just out of curiosity.
How would you DIY gurus construct your own jogwheel? I’m not asking for the mechanical solutions. I would like to know what kind of sensors you would use. Seen a few different solutions while browsing this forum and others.
And how would you implement touch sensitivity?
Would you make something different from the way jogs work on conventional controllers today?
Cheers
I made my own jogs with optical encoders that 512 pulses per rotation.
http://www.djtechtools.com/forum/showpost.php?p=381195&postcount=62
Did you buy the optical encoder or make your own disc and just buy the sensor?
If you could point me in direction of a good encoder that would be much appreciated.
And if I would want to go for the highest possible resolution, how would you guys do that?
Cheers for sharing!
I bought an Oak / Grigsby 91Q128-43-00110 encoder. This is an optical encoder that has everything in it. You get the highest resolution by reading all state changes ie this one will give you 512 transitions.
In my experience you don’t need much more than 512 cause of the limitations of the midi protocol. If you program a special HID then a lot more is possible depending on the speed of the protocol you use.
Anyone knows how the high resolution is achieved on commercial controllers?
Reloop states 4096/rev for the Jockey3ME
Denon says 2048/rev for MC6000 (Engine DJ Community - Product Resource & Community)
That same chart says 1000/rev on S4. Not saying that is right or not…
I’m guessing some might use optic sensors…
And, would there be an optimum amount of pulses for each size wheel?
lets say I would want to make a 200mm jogwheel. A 200mm jogwheel has a circumference of 628mm. With a resolution of 500/rev that would mean 1,25mm to change it’s value. Which might not quite cut it.
And I would want a sturdy jog, so I would probably go for an optic solution instead of an encoder.
What do you guys reckon?
Has any of you taken your controllers apart? how sturdy is the connection holding your jogs? Seen a few, but if you guys have pictures I love to see them!
There are no limitations in the MIDI protocol in this regard. These encoders are sending a RELATIVE message - not an absolute message. They can send a pulse as frequently as the transport mechanisim will allow.
If you wanted to get an encoder that sent a thousand pulses per revolution, this would be totally acceptable - both by the MIDI protocol and (I’m assuming) the Traktor software.
Even suggesting that the OP attempt an HID implementation is bordering on stupid. How then would the OP get the SOFTWARE to support his HID implementation? Do you expect that the folks at NI are going to expend resources supporting a one off home made controller?
There are plenty of encoders available at a reasonable price that offer higher resolutions (1000+ PPR). Just search for “incremental rotary encoder” and look for something that matches your needs.
PROTIP - To take stress off your rotary encoder, don’t directly couple the platter to the encoder shaft. Instead, use a “band and wheel” setup to transfer movement and absorb stress (see attachment).
As for touch sensitivity, that’s often referred to as “CapSense”. There are many ways to get this done, ranging from obtaining a dedicated chipset from someone like Cypress Electronics, to hitting up Arduino Playground and downloading the Capacitive Sensing Library and dedicating a few pins to it.
Typically there’s a lot of things going on. Sometimes they’re optical as you assume, and a single “eye” is reading a specific number of slots or teeth per rotation. Sometimes there are multiple optical readers offset in a way that when one reads a “1”, the other reads a “0”. Sometimes it’s an optical reader, but instead of slots or teeth, gray code or some similar method is used.
And sometimes its flat out cheating by simply multiplying the messaging in the firmware to up the resolution.
Thanks for sharing nem0nic, was thinking about a belt connection for another application, stupid of me not to think about it for this.
Still need to gather some more information before getting this project of the ground.
Thanks a lot so for everything so far lads!
//Joel
I’ve seen these premade capsense boards and did a bit of reading on the arduino capsense now.
I’m still not educated enough in electronics, so a few q’s spring to mind.
The “arduino-way” mentions a need for “proper” ground. How would you guys solve that? And would a capsense board/integrated component have the same issue?
Got me curious how that is done in commercial stuff again.
And also, they use aluminium foil, suppose it should work with sheetmatal to as long as it shares the same material properties (resistance).
Suppose I need to get some components and start experimenting.
We were talking about this here, maybe you find interesting info.
About traktor messaging and arduino.
http://hackmat.com/blog/?p=38&preview=true
Another thread:
Another about teensy and motorized platter:
I can’t read accurately the comments now but I will back!
Happy new year!
-m!
Wanna have fun? Use HDD motor + opamps. There is an instructable on it. Problematic with low speeds.
The problem with a motorized platter is that you need to then regulate the rotation speed precisely enough to allow for smooth audio playback. That’s more difficult than it seems if you’re considering cost.
I wouldn’t use a HDD, it isn’t reliable and will only cause frustrations especially if you don’t have a lot of electronic knowledge.
The encoders I have have bearings and have a very solid shaft. There is no wobble on the shaft. If there would be too much stress on them I replace them with another type but I don’t think that will happen with an easy mixing style. Scratching with these jogs wouldn’t work I guess, I only do beatmatching.
Concerning the midi protocol limitations. I use a midi to USB converter. Perhaps that is where my problem is. My encoders have 2 bit grey code and I read all pulses on Interrupt so I don’t miss one. When I move one jog very fast there is a limit on the RPM. Moving 2 jogs makes it worse. My microcontroller is fast enough, perhaps the converter not. For me no problem but that could be a point of improvement in my design. I find 512 pulses per rotation enough. If you want very large platters like +120mm you could need more.
I wonder if CDJ’s have that much pulses.
As for the touch sensor, look at some Capacitive sensor boards on ebay. They are cheap and very easy to use.
You could make some things with an Arduino but for high resolution jogs I don’t think that will work well.
Most of the higher end platter controllers have 3-4K pulses per revolution.
I’ve had a lot of success with these :
Basically you dangle a magnet above these chips and you get a (max)16384 pulse per revolution rotary encoder that can interface using SPI or I2C (easy protocols to use). They have good enough response to be used for even scratching.
Nice find, Rasteri. I’ve never used this type of solution, but I would suspect that it would be prone to jitter. Is this the case?
Yeah I thought so too initially, but it’s rock solid. I even tried holding other magnets nearby and it made no difference. I used the 12-bit (4096-step) encoders, maybe the 14-bit (16384) would be prone to jitter (but that’s really overkill IMHO).
Ow love the Hall-based encoders. Creating the encoder-jogdial connection is no easy with these (noone is a fan of rubber-bands.).
With 14bit == NRPN resolution, you could make a positional message out of that one. Not that one would need it, but, would solve any potentional “sticker drift” if you use it for scratch.
Yeah it was a standalone scratch-device I was using it in so having an absolute position was of huge benefit. I don’t know anything about using it in software though, can traktor read absolute positioning?
No, it can’t. At least not via it’s MIDI implementation. But I wish there was some support for it. Even a 7bit absolute message combined with a decent resolution relative message would eliminate any kind of drifting.
In fact, that’s how DVS timecode works.