Hi Keith



 KR> yes it sounded much better, what was wrong?



You want the long answer? Oh good. Well, as I mentioned, there's

only one timer in a 16C84, and it's busy timing the half cycles of

the notes. They're real notes, btw, a C program turns hertz into

nanoseconds per half cycle, and a macro in the Pic assembler turns

these into timer register loads. I keep track of realtime as well,

using a 10 mS "background" clock. I do this by adding a constant to

an accumulator in every timer interrupt, and comparing the

accumulator with 10mS in the main loop. The constant depends on the

current note, and is obtained from a lookup table generated by the

assembler macro mentioned above. The 10mS clock doesn't have to be

too accurate, so vibrato is ignored.



Now for the bug: the timer is a count-up device, not count-down.

Bit of a bugger, because I have to subtract the actual number of

timer cycles from $100 before loading it into the timer register. I

used to do this in the program itself, before it dawned on my

lightning fast brain that the macro could do it instead, saving one

program cycle (400nS). So I did it. Unfortunately, I did the

subtraction in the macro just before the section that calculated

the constant to be added to the 10mS clock accumulator, so the 10mS

clock was shot to bits. This controls note duration and vibrato

timing - it was the very slow vibrato on the eexxttrraa lloonngg

notes that was the real clue. Shifting the subtraction twenty lines

down fixed the problem.



I'll transfer the program to a 16C71 next. It has four 8 bit analog

inputs. With four pots I can control note duration, freq span and

offset, and vibrato depth (nausea level). Then it can replace the

hardware random note generator (Elektor magazine, yonks ago) that

currently runs off the workshop front door switch.



 KR> the choon, welllllllllllllll interesting is the term that i'd use.



One has to listen to it for some time before one appreciates its

presumption. The random number generator is really a random bit

generator, the new bit is stuffed into the bottom of a shift

register. Therefore, each successive number depends largely on the

previous number, and is therefore not truly random. This shows up

audibly when the shift register is full of zeroes or ones,

representing the bottom or top notes. The following few notes tend

to follow an ascending or descending scale, as the new bits travel

up the shift register. The cure seems to be to flush the shift

register by calling the random bit generator n times (n=bit size of

output number), but I think I'll leave it as is - it adds a bit of

charm...



 KR> its a lot cooler here thank goodness, i don't know how you handle it.



I reckon it's lovely weather, provided you don't have to do any

work. Find a shady spot with a bit of breeze, do nothing, and it's

not half bad.



We had 32mm during the day here yesterday. Bloody wonderful. Best

rain since 1991. The dam is 42.1% full (there's a blackboard up

there with this info on it), which means we won't have to buy

Burdekin Dam water for a year or so.



Cheers



--- PPoint 1.88