I'm all about configurability in software, since my intent is to design my own encoder, I can add zero speeds threshholds.
Like you said Ben, resolution of the value doesn't seem to be the issue, but that you can detect speed changes as soon as possible and transmit it. A grey-coded encoder may or may not cut it for this. I'm thinking if you need a response "independent" of encoder pitch you'd want an encoder with a suitably high resolution. I'm thinking optical as in optical mouse components like this guy: http://www.casainho.net/tiki-index.php?page=Homemade+MIDI+turntable Basically, for a jog wheel to be truly responsive, you need the encoder to update at least as fast as an acceptably fast normal button press would, but also contain the instantaneous velocity during that update. I think 7 bit data is probably good enough but if 14 bit were available, software that doesn't support 14 bit it can just ignore the LSB data. You could just script for the extra data byte, by masking the controller number byte (they differ by 32). Are static variables allowed in Mixxx scripting?. So here's what I'm proposing minimally: 1) Fast response sensor, addequate resolution 2) Not tied to an axial encoder, so the jog wheel can be whatever you want, (a turntable, an existing job wheel, etc) Just need to find spare time to finish implementing the USB MIDI protocol on the AVR32 UC3. -Nick ----- Original Message ---- From: Ben Wheeler <[email protected]> To: Nick Conway <[email protected]> Cc: Mark Glines <[email protected]>; [email protected] Sent: Thursday, March 12, 2009 7:25:52 AM Subject: Re: [Mixxx-devel] Midi Encoder data details The Xponent (I used to have one but don't anymore, so this is from memory) works similar to the Total Control but the "zero point" is 63 or 65. Values less than 63 are anti-clockwise, more than 65 are clockwise. I never read any meaning into the frequency at which the CCs were transmitted (mainly because I didn't see any easy way to do it in mixxx); the value itself seemed to adequately convey the speed of rotation. The full value range was never used in practice, you'd need to apply an electric drill to get anywhere near 127 or 0. So I added a sensitivity adjustment within mixxx to scale it in a user- configurable way (all of which has probably now disappeared from the code...). Ideally, one *would* also look at the frequency of the incoming CCs so that you'd be able to spot when rotation has stopped but the encoder has not transmitted 63 or 65, which did happen sometimes. In fact I think I broadened the zero range a bit to prevent the risk of drift. Even the slowest real turning of the wheel in normal use would produce values of 3-5 away from 64 so this was no problem. Ben ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
