IF and lookup table limits

K

Kecked

Member
I am doing a music sequencer which requires 88 separate states ie notes. I am using a pot read into an adc that divides the pot range into 12 ranges that correspond to each basic note a,a#,b,c....
I then have a second pot that I do the same thing to that determines which octave the note is in. I want to then use logic to determine the note and look up a value from a table that determines a value for a DAC tha tproduces the correct voltage for my synth. Here is my issue. Before I even begin. Can I have a lookup table with 88 elements determined by 2 separate parameters?


The second way to do it is with 88 if then statements but I already know I am limited to 21 of them. The pdf show the logic I'm looking at. The hardware is just two pots on an adc. The final determined note value for the DAC will be sent SPI to a yet to be determined 16bit or greater dac based on what is needed for accuracy.

Basically its two adc lines that determine a value that is output to a dac. Not rocket science but I want to make sure I don't hve some limit before I start and to see if there is a smarter way to do this.
Fortunately, the notes will only change at most a few times a second so speed should not be an issue. I also do not want this to be midi which isthe obvious solution as it is being feed by an analog multiplex sequencer. (see my post in the porjects for details if you want).
View attachment Note Selector.pdf
 
hippy

hippy

Technical Support
Staff member
It all sounds possible. Though you can only have Eeprom or Table indexed by one parameter you can combine two parameters to create the one ...

ReadAdc ... note
ReadAdc ... octave
Let note = ... something to give 0 to 11
Let octave = ... something to give 0 to N
Let index = octave * 12 + note
Read index, valueForOutput
 
B

boriz

Senior Member
Sure you want to go with Pot's? Not very accurate, and notoriously susceptible to noise and wear+tear.

A much better method would be a digital rotary encoder, something like this: http://www.ebay.co.uk/itm/10-Pcs-12mm-Rotary-Encoder-Switches-360-Shaft-Dia-6mm-New-/170893350236?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item27ca09955c

It also includes a push button action for 'select' or to swap between changing the note and changing the octave/tempo/measure, whatever.

I've some code for this type of encoder around here someplace. I'll have a look.

Also. What's all this 0.83333333 and 3.916666667 stuff? You know Picaxe only uses integers right?
 
K

Kecked

Member
all excellent thoughts thank you both. the long numbers are calculated volatges tha the DAC will produce. I will have to play with the numbers to find the right binary to send to the dac to make the voltage I want. The table just was to say when this and that are true send this value to the dac.

I have not ever tried a digital encoder. That is the only reason I didn't try it yet. maybe it is time to do so. I am still confused on the direction encoding thing and how to use them. I'm sure there are lots of tutorials out there. After all the pics were voodoo to me just a short while ago.

Since the hardware is soo simple I think I will try both of your ideas. IE case statements and combined values. I like the combined value approach best as it allows me to just store 88 values in memory and use case statements to encode the pot position.

Sometimes I think I am a fool trying to use analog when digital works soo well. I already have a midi to voltage convertor so I could just use my laptop and a midi cable but what fun whould that be and I would loose out getting to learn digital pots!

Boriz that code of yours would be helpful to see it work and reverse engineer from.

Wish me luck.
 
Last edited:
M

MartinM57

Moderator
Buzby

Buzby

Senior Member
Hi Kecked,

I might have missed something here, so apologies if I've jumped in the wrong end.

Why do you need pots/dials/encoders ?

Could you not just use a keyboard to enter the numbers directly ?

With very little code a 4x4 matrix would give 4 octaves and 12 notes, each on a single key.

Just a little more code and you could enter any octave and any note.

Cheers,

Buzby
 
K

Kecked

Member
The idea is accurate notes on a sequencer. The sequencer is a device with 16 channels that are scanned via a multiplexer. Normally you just ouput the raw voltage across a set of pots. I was thinking to get the best of both worlds by making it possible to accurately set notes and then scan that volatge via the sequencer section. It is real hard to set a note with a single turn pot and tedious to tune each note even with a multi turn pot. So this looked like a way to get the look and feel of the old moog sequencer with the accuracy of the digital world.

Here is the thread I started http://www.picaxeforum.co.uk/showthread.php?22384-16-channel-analog-voltage-sequencer-for-analog-synthesizers
The ditial pot thing has been off my radar because it is confusaing to me. I get the gray code and how the one bit chages or the other determining the direction. Just making that in code is going to take me some time to get and interupts are totally new. Again I get the concept I just don't have the code skills yet but they are coming. I thought I'd never learn spi or i2c and I got that so I'll get it it just takes me a while. I'm an old man I didn't learn this stuff as a youth.
 
P

Paix

Senior Member
I'm probably way off base, so please forgive me if I'm wrong.

I have picked up on Quadrature and Gray code from the conversation, but not necessarily in context. Gray code is designed so that only one bit changes at a time so that there is no chance of getting invalid glitches due to sensor alignment etc. I am not sure that it necessarily gives direction information easily. It strikes me as far from being intuitive which is why it doesn't appear to be more popular than it is.

Mechanical (ball) mice use a nice litle rotary encoder chip that produces quadrature signals, the relative phase of which does give directional information. An old mouse is also a very reasonable source of cheap parts for a rotary encoder. Looking for a dedicated rotary encoder device appears to have an eye watering effect upon the wallet - or at least used to do. Off thread but hopefully of some relevance.
 
hippy

hippy

Technical Support
Staff member
The nature of Gray Code is , as you say, if you have a line of sensors reading the code disc, when the value changes only one sensor will ever change at that time.

With binary, say going from 3 to 4 ( %011 to %100 ) three bits change and if the sensor were not perfectly aligned you would get one bit change before another, perhaps see %011, then %111, then %101, and only then %100; 3 to 4 becomes 3 to 7 to 5 to 4 which is a lot of noise and error you don't want to have to handle !

To determine direction from Gray Code, simply convert Gray Code to decimal, and see if the value increased or decreased.
 
Buzby

Buzby

Senior Member
Paix said:
Gray Code... It strikes me as far from being intuitive which is why it doesn't appear to be more popular than it is.
... Looking for a dedicated rotary encoder device appears to have an eye watering effect upon the wallet
Click to expand...
It is very popular !. Virtually everyone of those 'absolute' encoders use Gray code.
But to get high resolution they need a very fine pitched optical disk, hence the eye watering prices !.

Just for fun, see the attached program for generating codes of all kinds.

Cheers,

Buzby
 

Attachments

You must log in or register to reply here.
Top