[sdiy] Alternatives to Faders

[Edward King]

Tom,

Ive created some additional CAD work, circuit diagrams and stuff for those 
who want to give this a try (including the maths and code for determining 
best-fits for wheel and encoder size and how to configure appropriate lookup 
tables and other code and electronic elements).
For example, there will be those who would rather take the output from the 
sensors directly (such as myself) and process those than to re-use the 
onboard encoder chip that you usually get.

I will forward this stuff on to you this evening and anyone else who wants 
it can let me know.

Regards

Edward

p.s Other stuff added inline

----- Original Message ----- 
From: "Tom Wiltshire" <tom at electricdruid.net>
To: "Edward King" <edwardcking2001 at yahoo.co.uk>
Cc: "Synth-DIY" <synth-diy at dropmix.xs4all.nl>
Sent: Wednesday, March 07, 2007 11:40 PM
Subject: Re: [sdiy] Alternatives to Faders


> Edward,
>
> On 7 Mar 2007, at 20:43, Edward King wrote:
>>
>>> A final problem that your recycled-mouse idea might have avoided is that 
>>> commercial rotary encoders often don't have that many positions per 
>>> rotation - 24 pulses per rotation is a common value, although by no 
>>> means the only one available. This makes doing large changes of high 
>>> resolution controls quite difficult. If the control has a 16 bit 
>>> resolution and one full turn takes you from 0 to max (65536) then each 
>>> of the 24 clicks represents 2730 units. How then to make a parameter 
>>> value jump 2730 units without an abrupt change?
>>>
>>> Sorry not to offer more positive suggestions, but this is definitely 
>>> still a problem for which a really good solution is yet to be found.
>>
>> I think theres some confusion here about position sensing and rate. Ball 
>> mice feed rate data back (the amount that their position has changed 
>> since the last 3 byte value) not absolute position.
>> Because you're measuring rate of change rather than absolute position, 
>> moving the wheel slowly gives you fine control and moving it quickly 
>> gives you coarse control.
>> If you really want the parameter to jump from 0 to max, just flick the 
>> wheel forward and you get the abrupt change you desire.
>
> Yes, I see what you're getting at now. Whilst there are absolute position 
> rotary encoders available, I was thinking of the kind that output two 
> pulse trains 90 degrees out of phase. I'd been thinking of simply counting 
> the pulses to give you relative position information (move +5, or 
> move -15, for example) but I can see that measuring the _rate_ of those 
> output pulses is in many ways more useful. As you suggest, you can map the 
> rate information to the increment, so that faster movements take you 
> further, and slower movements steps through the values one by one.

No. Those rotary encoder things are great for general parameter control, but 
I wanted something with much more scope.


>
> Thanks, I'll have to think about this some more...
>
> Regards,
> Tom
>
> PS: Btw, it was me mentioned hexadecimal. All I meant was that 255 is only 
> a number that has significance in binary/hex/octal - I wasn't suggesting 
> anyone would actually display anything in hex. Imagine: Mod depth=2C! 
> yurg!

LoL

I know. I did wonder what you'd been drinking...

>
>
> ++++ Electric Druid ++++
> Web Design & Development
> http://www.electricdruid.net
>
> 


		
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html