A speed-tatstic way to look up a value? (LUTs)

[cncmachineguy]

based on your chart, I would look first to see if count < 10000. thats the one to take care of the quickest. then check somewhere between 10000 and 65000.

Of course when you find the range, just use if then like you posted

[cncmachineguy]

How bout something like this?

'Is this the right symbel for comments?
'This is what I'm using it for
'
'Assuming count is the number to be checked
'
'This set of checks breaks it into 3 16 possible chuncks

If count < 3800 then ERROR                            ' count under 3800 must be wrong, but it could mean TMR rolled over
If (count <= 9288) and (count >= 3800) then LowCount ' 
If count <= 23404 then MidCount                       ' no need to check lower limit because that was in last check
if count <= 62479 then HighCount                      ' still no lower check

'now do the same for the each section:

LowCount
if count <= 4920 then LLowCount
if count <= 6568 then MLowCount
' must be High low count
'at this point do another chunck break or code for all possibles
'another chunck break

if count <=8275 then LhLowCount
'choice of 4 now
'at this point count MUST be >8275 and <=9288

LhLowCount ' count between 6569 and 8275
if (count >=6569) and (count <=7372) then note=4D : goto NoteFound
If (count >=7371) and (count <=7372) then note=4C : goto NoteFound
if (count >=7810) and (count <=8275) then note=4B : goto NoteFound

Dose this make any sense? I think there is a problem with your numbers, but it could be me. Seems like high and low of next up note are reversed. For instance note 4D is 7372-6957, and 4C is 7811-7371.

[HankMcSpank]

Hi Bert,

I wil digest your code a bit later (seriously, to my untrained eye, everything takes a while decipher & get my head around!). As it goes it seems pretty whippy already (ie just running through the whole 50 deep LUT, top to bottom)...

Here's a quick video I've just made....

(to be able to see what's going on in it, you really need to watch in full screen mode *and* 720p, which I don't know how to embed - these options can be chosen looking at the video directly on you tube via this URL ).....



Green trace is audio 'input' signal (a sine wave sent into my circuit from a synth), the yellow trace is the same signal but squared up (feeding into the PIC's comparator1), the data to the left of the scope is the midi info as transmitted out of the PIC.

the full signal path is as follows...

Synth audio sine wave signal-> squaring cct-> pic comparator->interrupt counter -> PIC LUT ->PIC then outputs midi data using HSEROUT-> into a PC MIDi In port->into an app callec MID- OX (A midi interpreter/viewer - which is what that window/data to the left in the video is)

So the sine wave jumping about is actually me playing different notes on a synth (& thereby changing the sine wave frequency into the PIC - to test the PIC frequency detection & conversion to MIDI)


PS btw I had the data the wrong way round when I posted earlier - the LUT condition was not being met, here it is corrected...

if (comp1time>= 52538 AND comp1time <= 55663) then note = $2A
if (comp1time>= 49589 AND comp1time <= 52539) then note = $2B
etc etc

So maybe I don't need a binary search algorithm, but every little helps wrt to speed, so may still explore that avenue.

[cncmachineguy]

Hank, if it works dont fix it. or if it isn't broke, fix it till it is. lol

Seriously, the only thing i would do is make sure and run your test from the bottom up. By this I mean, check for the low count first on up th to highest count. then you can be sure to have enough time. . Something else about your linear search, Y only need to test for 1 condition in each next IF after the first. heres why:

First check establishes a range, say 3800-3900, if this fails, number must be > 3900. next check just needs to look for <4000 cuz you know its >3900. next check if <4200,again because it must be >3900. and so on. Of course my numbers are fictious, but you should get the point. Only checking 1 condition should almost double the execution speed (half the processing).

the code I posted is not complete, it shows how to go through the levels of searching.

[HankMcSpank]

Well the acid test is when I play a guitar into it & the pic 'triggers' a sound in midi synth module.

A bass E string 'period' is about 12ms (82.4Hz) ....add in the overhead that detecting the frequency will entail, then it's going to be higher.

They reckon the average musician can detect about 10ms of latency (ie from hitting a key, banging a drum,plucking a string .... to actually hearing the sound) so I'm already behind the curve so to speak. The commercial 'guitar to midi' converters pull this frequency 'detection time' in by detecting half a period....so for 82.4Hz, that'd be about 6ms - safely under the 10ms level - but I reckon that'd need a 40Mz oscillator to have the necessary granularity.

So perhaps it's better to go top down (the bass frequencies are at the top of the list), just to rescue back a little bit of 'processing time' for those lower frequencies (for example a 1Khz 'period' is 1ms, so I've far more time to play with vs lower frequencies.)