That will be hell to replace when it fails.justin3am wrote:What I've heard from a former Alesis employee is that each endless pot has two resistive elements that work in opposing directions. So as you turn the pot in either direction you are increasing the resistance for one element and reducing resistance for the other. I think the pulses are derived via some quantizing method in firmware. Supposedly, the Alesis Micron and Akai MPK keyboards use this kind of endless pot. I haven't had a chance to completely disassemble my MPK, but I can see that each rotary control element has 4 leads!Nantonos wrote:But if they really combined them ... say 16 pulses per turn and 16 linear pot segments between the pulses. So you get analog resolution between the pulses, count pulses to get the coarse resolution, and can multiturn. Once a pulse happens you count it and the analog slider probably hits an earth point momentarily then goes onto the next resistive segment.
Plus, you might only need one channel of pulses because the analog value would show which way you are turning.
No, I hadn't heard of them, but thanks for alerting me to the concept.
Kinda interesting. Still, I can't find any information about these parts, so I don't know if they are only being custom made for Alesis/Akai/Numark or what.
HD Midi
-
- KVRAF
- 6323 posts since 30 Dec, 2004 from London uk
-
- Banned
- 1374 posts since 5 May, 2007 from Finland
You are overcomplicating things. Just do what i suggested. Go for a purpose built controller like Mackie, Automap or maybe this: http://www.steinberg.net/en/products/co ... mc_fd.htmlbmrzycki wrote:All good questions. What I'd really like is a high-quality encoder with a large knob. Something the size of a jog wheel or a hockey puck. I could then connect its output to the GPIO pins on a device like the Raspberry Pi. Then I'd use Linux (with RTOS extensions) to generate the appropriate midi messages. I'd also like to use an android app or windows/mac app to send commands to the RPi over bluetooth or WiFi to change how the messages are sent. It also allows me to decide if the messages are CC, MSB/LSB CC, Pitchbend, Aftertouch, RPN,NRPN, (and if I can ever figure it out) Mousewheel up and down.Nantonos wrote:How would you want it to work? Acceleration based on turning speed? Or a fine/coarse knob pair? Or concentric knobs? Weighted knobs?bmrzycki wrote:
I would gladly pay $200-$300 for a single, high-quality encoder with a mechanism to quickly switch between parameters. Most of the stuff I've tried falls laughably short as it tries to to everything.
Concentric LED feedback (coarse) or a numerical display of the value, or ...
Would you also want control over the acceleration curves?
How many parameters do you want to switch between? For a small number, assignable buttons would work. For a larger number, I guess its down to menus; scrolling through a large number of options is slow, though.
Any would you want NRPN, RPN, MSB/LSB or all three?
I know that's pretty much unmarketable but that'd be my ideal setup. It'd allow for a clean, touchable interface on the android and a good tactile knob that can dynamically change tasks. A Nexus 7 + RPi is about $250 and all that's left is a good knob.
- KVRAF
- 4130 posts since 11 Aug, 2006 from Texas
I own a Novation SL ZeRO and it leaves a lot to be desired. Automap caused me more frustrations than it gave me workflow enhancements. On top of that the endless encoders are detented, something I do not like.mkdr wrote:You are overc complicating things. Just do what i suggested. Go for a purpose built controller like Mackie, Automap or maybe this: http://www.steinberg.net/en/products/co ... mc_fd.html
I owned a BCR2000 in the past and wish I still had it. I liked the feel of the knobs the best. Even so it was still difficult to work with remembering what knob did what and the fine resolution in inc/dec mode was not very good.
The CMC devices require using cubase to get the full effect from. I really have tried other solutions and was generally disappointed.
I only have 2 hands. If I have a good, high-quality encoder and a mechanism to quickly shift what it does on the fly I'm set.
-
- KVRist
- 67 posts since 13 Aug, 2012 from France
Oh! That is way easier than I was considering. Same hardware (big heavy weighted knob), but also something like a Teensy 3.0 (Arduino-like, but ARM based and with native USB MIDI) inside to make the messages. Plus some preset buttons to change between commonly used CCs and an LCD screen for configuration ... I found a couple of 128-position encoders on Farnell, they are also ball-bearing based and rated for 3,000 rpm so something like a 5:1 ratio between knob turning and encoder turning would give 640 impulses per turn which seems like a good resolution; you could still spin the knob fast (up to 10 revolutions per second).bmrzycki wrote:All good questions. What I'd really like is a high-quality encoder with a large knob. Something the size of a jog wheel or a hockey puck. I could then connect its output to the GPIO pins on a device like the Raspberry Pi. Then I'd use Linux (with RTOS extensions) to generate the appropriate midi messages.
Since you want to do all the heavy lifting on other devices, it seems easier to make.bmrzycki wrote:I'd also like to use an android app or windows/mac app to send commands to the RPi over bluetooth or WiFi to change how the messages are sent. It also allows me to decide if the messages are CC, MSB/LSB CC, Pitchbend, Aftertouch, RPN,NRPN, (and if I can ever figure it out) Mousewheel up and down.
I know that's pretty much unmarketable but that'd be my ideal setup. It'd allow for a clean, touchable interface on the android and a good tactile knob that can dynamically change tasks. A Nexus 7 + RPi is about $250 and all that's left is a good knob.
Although, the RPi would need to register as a multiclass MIDI+Mouse device, to send mousewheel as well.
- KVRAF
- 4130 posts since 11 Aug, 2006 from Texas
I'm more of a software guy so I tend to think of solutions that use code and not physical devices. I'd rather write low-speed daemons in Python and compute-intensive sections in C and be done with it.Nantonos wrote:Same hardware (big heavy weighted knob), but also something like a Teensy 3.0 (Arduino-like, but ARM based and with native USB MIDI) inside to make the messages.
If you do ever purchase a high-quality encoder I'm very interested in your results with it. I may end up purchasing a similar device if your results are favorable.Nantonos wrote:Plus some preset buttons to change between commonly used CCs and an LCD screen for configuration ... I found a couple of 128-position encoders on Farnell, they are also ball-bearing based and rated for 3,000 rpm so something like a 5:1 ratio between knob turning and encoder turning would give 640 impulses per turn which seems like a good resolution; you could still spin the knob fast (up to 10 revolutions per second).
That's a bit of the point really. I think I know what I want until I start using it, then I realize I want something different. Android has a free SDK and Linux is open source. I found a RPi-like device that has USB-otg built-in called the Cubieboard. I'd have to learn how to program USB MIDI (and mouse) but if I got it to work I could just move my mouse and then turn the wheel. Most DAWs and plugins respond to it nicely. I got the idea from Novation's Speed Dial knob, a very clever approach.bmrzycki wrote:Since you want to do all the heavy lifting on other devices, it seems easier to make. Although, the RPi would need to register as a multiclass MIDI+Mouse device, to send mousewheel as well.
It also has the ability to grow if more stuff supports OSC and I can make touch interfaces on the tablet that will route midi through, bypassing a lot of the problems with MIDI Wifi bridges.
- KVRian
- Topic Starter
- 1253 posts since 31 Dec, 2008
Seams MIDI creators are meeting at next NAMM, fingers crossed
http://www.youtube.com/watch?v=jea_gmN417o
http://www.midi.org/midi30/
http://www.youtube.com/watch?v=jea_gmN417o
http://www.midi.org/midi30/
- KVRian
- Topic Starter
- 1253 posts since 31 Dec, 2008